ZFS file storage info

[Matt Reimer]

On Fri, Feb 12, 2010 at 3:50 PM, Ivan Voras <ivoras at freebsd.org> wrote:

> Hi,
>
> Because of ZFS' interesting way of storing files, I'm wondering if there is
> a way to get information such as how fragmented a file is? I'm thinking
> about something like an utility that for a given file gives "file X is
> stored in Y fragments"?
>

[root at gandalf ~]# ls -li /usr/bin/vi
6987 -r-xr-xr-x  6 root  wheel  337136 Nov 21 14:31 /usr/bin/vi

[root at gandalf ~]# zdb -ddddd glamdring/usr 6987
Dataset glamdring/usr [ZPL], ID 31, cr_txg 97, 1.59G, 77833 objects, rootbp
[L0 DMU objset] 400L/200P DVA[0]=<0:10800c33e00:600>
DVA[1]=<0:21000487800:600> fletcher4 lzjb LE contiguous birth=3345
fill=77833 cksum=1189b0387a:6d5fe773294:15d9bc7539ad2:2fb4ba66521d1e

    ZIL header: claim_txg 0, seq 0

first block: [L0 ZIL intent log] 20000L/20000P DVA[0]=<0:1b9730000:30000>
zilog uncompressed LE contiguous birth=3233 fill=0
cksum=7fb9ac2ef6d387ee:edbcafeec75face4:1f:1

Block seqno 1, won't claim, [L0 ZIL intent log] 20000L/20000P
DVA[0]=<0:1b9730000:30000> zilog uncompressed LE contiguous birth=3233
fill=0 cksum=7fb9ac2ef6d387ee:edbcafeec75face4:1f:1


    Object  lvl   iblk   dblk  lsize  asize  type
      6987    2    16K   128K   384K   388K  ZFS plain file
                                 264  bonus  ZFS znode
path /bin/ex
uid     0
gid     0
atime Sat Feb 13 07:37:52 2010
mtime Sat Nov 21 14:31:07 2009
ctime Fri Feb 12 05:52:32 2010
crtime Fri Feb 12 05:52:32 2010
gen 145
mode 100555
size 337136
parent 4
links 6
xattr 0
rdev 0x0000000000000000
Indirect blocks:
               0 L1  0:10bef000:c00 4000L/400P F=3 B=145
               0  L0 0:10bf0000:30000 20000L/20000P F=1 B=145
           20000  L0 0:10c30000:30000 20000L/20000P F=1 B=145
           40000  L0 0:10c70000:30000 20000L/20000P F=1 B=145

segment [0000000000000000, 0000000000060000) size  384K

You're interested in the "Indirect blocks" portion. Google raidzmap.tar.gz,
download and build it, then do the following. Note that you'll drop the
third portion of the zfs offset tuple (e.g. the "c00" in 0:10bef000:c00) and
use the physical size (the hex number next to the "P" in "400P"). The devidx
numbers correspond to the devices comprising the pool, zero-based.

The offset numbers are the hex offset in blocks from the beginning of the
disk.

In the list of physical blocks the parity blocks come first, then the data
blocks. Firstdatacol is the offset into the list of physical blocks where
the data blocks begin. For example, in the first raidzmap command below,
firstdatacol is 2 which corresponds to "devidx = 0, offset = 2ca7e00, size =
200".

IIRC, YMMV, etc.

[root at gandalf ~]# ./raidzmap glamdring:0:10bef000:400
Columns = 4, bigcols = 4, asize = c00, firstdatacol = 2
devidx = 4, offset = 2ca7c00, size = 200
devidx = 5, offset = 2ca7c00, size = 200
devidx = 0, offset = 2ca7e00, size = 200
devidx = 1, offset = 2ca7e00, size = 200

[root at gandalf ~]# ./raidzmap glamdring:0:10bf0000:20000
Columns = 6, bigcols = 0, asize = 30000, firstdatacol = 2
devidx = 0, offset = 2ca8000, size = 8000
devidx = 1, offset = 2ca8000, size = 8000
devidx = 2, offset = 2ca8000, size = 8000
devidx = 3, offset = 2ca8000, size = 8000
devidx = 4, offset = 2ca8000, size = 8000
devidx = 5, offset = 2ca8000, size = 8000

[root at gandalf ~]# ./raidzmap glamdring:0:10c30000:20000
Columns = 6, bigcols = 0, asize = 30000, firstdatacol = 2
devidx = 2, offset = 2cb2a00, size = 8000
devidx = 3, offset = 2cb2a00, size = 8000
devidx = 4, offset = 2cb2a00, size = 8000
devidx = 5, offset = 2cb2a00, size = 8000
devidx = 0, offset = 2cb2c00, size = 8000
devidx = 1, offset = 2cb2c00, size = 8000

[root at gandalf ~]# ./raidzmap glamdring:0:10c70000:20000
Columns = 6, bigcols = 0, asize = 30000, firstdatacol = 2
devidx = 4, offset = 2cbd400, size = 8000
devidx = 5, offset = 2cbd400, size = 8000
devidx = 0, offset = 2cbd600, size = 8000
devidx = 1, offset = 2cbd600, size = 8000
devidx = 2, offset = 2cbd600, size = 8000
devidx = 3, offset = 2cbd600, size = 8000

Matt