Hello all, I have a question about what output "ZDB -dddddd" should
produce in L0 DVA fields. I expected there to be one or more
same-sized references to data blocks stored in top-level vdevs
(one vdev #0 in my 6-disk raidz2 pool), as confirmed by the source:
http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/zdb/zdb.c#sprintf_blkptr_compact
And I do see that for some of my files as singular DVA entries with
blocks sized 0x30000 (I believe that's 0x20000 = 128k data plus
0x10000 = two parities). However on one file I have a series of
two DVA entries, sized 0x39000 + 0x3000. The file is not copies=2
as far as I know, but can be compressed and/or deduped.
Samples of zdb output are attached below; the strange output
goes on for all 47Mb of the file in 128kb increments.
Can someone plz help explain these values? :)
On a side note, what's the easiest way to retrieve the block pointer
(and checksum) pointing to a certain block of file's contents, and
how can I recalculate the SHA256 checksum for the block's raw data
(extracted with ZDB), so that I can see how the checksum mismatches
the data and what the differences seem like?
Thanks to DD I know that the error in the file is at offset of
3840 512-byte sectors and stretches 256 sectors, so it consumes
the 128Kb block starting at 0x1E0000. There it is:
1e0000 L0 0:84dfa316000:39000 0:9a0d61ac000:3000 20000L/20000P F=1
B=324766192/324766192
I extracted that with ZDB, pointing it at a somewhat random DVA
(since I don't know how to properly interpret them in this case):
# zdb -R pool 0:9a0d61ac000:20000 > /tmp/ext.1e0000+20000.txt
# zdb -R pool 0:9a0d61ac000:20000:r > /tmp/ext.1e0000+20000.bin
Now I wonder what the original BP checksum was, and how to compare
it "manually"...
Finally, if the file has one "segment" line in the end, does it
mean that it was not deduplicated with any other blocks (and is
stored contiguously)?
Thanks,
//Jim Klimov
=== ZDB output samples: strange output
Dataset pool/mydata [ZPL], ID 281, cr_txg 291705, 850G, 338171 objects,
rootbp DVA[0]=<0:49c1a790000:3000> DVA[1]=<0:29767208000:3000> [L0 DMU
objset] sha256 lzjb LE contiguous unique double size=800L/200P
birth=325604000L/325604000P fill=338171
cksum=a3688c0fe5542424:fd7669a381e1e00f:517ddd86c742e1d9:e0ec04feaef1b341
Object lvl iblk dblk dsize lsize %full type
291793 3 16K 128K 58.0M 46.4M 100.00 ZFS plain file
(K=inherit) (Z=inherit)
176 bonus System attributes
dnode flags: USED_BYTES USERUSED_ACCOUNTED
dnode maxblkid: 370
path /dir/myfile.zip
uid 1029
gid 10
atime Fri Jul 22 18:54:01 2011
mtime Fri Nov 16 08:25:04 2007
ctime Fri Jul 22 18:54:01 2011
crtime Fri Jul 22 18:53:36 2011
gen 324766191
mode 100700
size 48509480
parent 291760
links 1
pflags 40800000040
Indirect blocks:
0 L2 0:85ecc9a3000:3000 0:9b119832000:3000 4000L/400P
F=371 B=324766199/324766199
0 L1 0:856a554f000:6000 0:9b094233000:6000 4000L/1a00P
F=128 B=324766194/324766194
0 L0 0:8512195c000:39000 0:9b012003000:3000
20000L/20000P F=1 B=324766191/324766191
20000 L0 0:8512195f000:39000 0:9b012006000:3000
20000L/20000P F=1 B=324766191/324766191
40000 L0 0:85121962000:39000 0:9b012009000:3000
20000L/20000P F=1 B=324766191/324766191
60000 L0 0:85121965000:39000 0:9b01200c000:3000
20000L/20000P F=1 B=324766191/324766191
80000 L0 0:85121968000:39000 0:9b01200f000:3000
20000L/20000P F=1 B=324766191/324766191
...
2dc0000 L0 0:85e17e45000:39000 0:9b109acd000:3000
20000L/20000P F=1 B=324766199/324766199
2de0000 L0 0:85e1b865000:39000 0:9b10b576000:3000
20000L/20000P F=1 B=324766199/324766199
2e00000 L0 0:85e1b868000:39000 0:9b10b579000:3000
20000L/20000P F=1 B=324766199/324766199
2e20000 L0 0:85e1b86b000:39000 0:9b10b57c000:3000
20000L/20000P F=1 B=324766199/324766199
2e40000 L0 0:85e1b874000:39000 0:9b10b585000:3000
20000L/20000P F=1 B=324766199/324766199
segment [0000000000000000, 0000000002e60000) size 46.4M
=== ZDB output samples: expected output
Most other files, including those on deduped datasets, have
expected-looking entries going like this:
Indirect blocks:
0 L2 0:ac8ccf22000:3000 0:923f8364000:3000 4000L/600P
F=1176 B=325189629/325189629
0 L1 0:ac8b8b7f000:6000 0:923efca3000:6000 4000L/1800P
F=128 B=325189615/325189615
0 L0 0:ac8b5a65000:30000 20000L/20000P F=1
B=325189613/325189613
20000 L0 0:ac8b5a95000:30000 20000L/20000P F=1
B=325189613/325189613
40000 L0 0:ac8b5ac5000:30000 20000L/20000P F=1
B=325189613/325189613
...
//Jim
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
