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:


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)?

//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 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


zfs-discuss mailing list

Reply via email to