Jim Mauro wrote:
>
> Hey Max - Check out the on-disk specification document at
> http://opensolaris.org/os/community/zfs/docs/.
>
> Page 32 illustration shows the rootbp pointing to a dnode_phys_t
> object (the first member of a objset_phys_t data structure).
>
> The source code indicates ub_rootbp is a blkptr_t, which contains
> a 3 member array of dva_t 's called blk_dva (blk_dva[3]).
> Each dva_t is a 2 member array of 64-bit unsigned ints (dva_word[2]).
>
> So it looks like each blk_dva contains 3 128-bit DVA's....
>
> You probably figured all this out already....did you try using
> a objset_phys_t to format the data?
>
> Thanks,
> /jim
Ok. I think I know what's wrong. I think the information (most likely,
a objset_phys_t) is compressed
with lzjb compression. Is there a way to turn this entirely off (not
just for file data, but for all meta data
as well when a pool is created? Or do I need to figure out how to hack
in the lzjb_decompress() function in
my modified mdb? (Also, I figured out that zdb is already doing the
left shift by 9 before dumping DVA values,
for anyone following this...).
thanks,
max
>
>
>
> [EMAIL PROTECTED] wrote:
>> Hi All,
>> I have modified mdb so that I can examine data structures on disk
>> using ::print.
>> This works fine for disks containing ufs file systems. It also works
>> for zfs file systems, but...
>> I use the dva block number from the uberblock_t to print what is at
>> the block
>> on disk. The problem I am having is that I can not figure out what
>> (if any) structure to use.
>> All of the xxx_phys_t types that I try do not look right. So, the
>> question is, just what is
>> the structure that the uberblock_t dva's refer to on the disk?
>>
>> Here is an example:
>>
>> First, I use zdb to get the dva for the rootbp (should match the
>> value in the uberblock_t(?)).
>>
>> # zdb -dddd usbhard | grep -i dva
>> Dataset mos [META], ID 0, cr_txg 4, 1003K, 167 objects, rootbp [L0
>> DMU objset] 400L/200P DVA[0]=<0:111f79000:200>
>> DVA[1]=<0:506bde00:200> DVA[2]=<0:36a286e00:200> fletcher4 lzjb LE
>> contiguous birth=621838 fill=167
>> cksum=84daa9667:365cb5b02b0:b4e531085e90:197eb9d99a3beb
>> bp = [L0 DMU objset] 400L/200P
>> DVA[0]=<0:111f6ae00:200> DVA[1]=<0:502efe00:200>
>> DVA[2]=<0:36a284e00:200> fletcher4 lzjb LE contiguous birth=621838
>> fill=34026 cksum=cd0d51959:4fef8f217c3:10036508a5cc4:2320f4b2cde529
>> Dataset usbhard [ZPL], ID 5, cr_txg 4, 15.7G, 34026 objects, rootbp
>> [L0 DMU objset] 400L/200P DVA[0]=<0:111f6ae00:200>
>> DVA[1]=<0:502efe00:200> DVA[2]=<0:36a284e00:200> fletcher4 lzjb LE
>> contiguous birth=621838 fill=34026
>> cksum=cd0d51959:4fef8f217c3:10036508a5cc4:2320f4b2cde529
>> first block: [L0 ZIL intent log] 9000L/9000P
>> DVA[0]=<0:36aef6000:9000> zilog uncompressed LE contiguous
>> birth=263950 fill=0 cksum=97a624646cebdadb:fd7b50f37b55153b:5:1
>> ^C
>> #
>>
>> Then I run my modified mdb on the vdev containing the "usbhard" pool
>> # ./mdb /dev/rdsk/c4t0d0s0
>>
>> I am using the DVA[0} for the META data set above. Note that I have
>> tried all of the xxx_phys_t structures
>> that I can find in zfs source, but none of them look right. Here is
>> example output dumping the data as a objset_phys_t.
>> (The shift by 9 and adding 400000 is from the zfs on-disk format
>> paper, I have tried without the addition, without the shift,
>> in all combinations, but the output still does not make sense).
>>
>> > (111f79000<<9)+400000::print zfs`objset_phys_t
>> {
>> os_meta_dnode = {
>> dn_type = 0x4f
>> dn_indblkshift = 0x75
>> dn_nlevels = 0x82
>> dn_nblkptr = 0x25
>> dn_bonustype = 0x47
>> dn_checksum = 0x52
>> dn_compress = 0x1f
>> dn_flags = 0x82
>> dn_datablkszsec = 0x5e13
>> dn_bonuslen = 0x63c1
>> dn_pad2 = [ 0x2e, 0xb9, 0xaa, 0x22 ]
>> dn_maxblkid = 0x20a34fa97f3ff2a6
>> dn_used = 0xac2ea261cef045ff
>> dn_pad3 = [ 0x9c2b4541ab9f78c0, 0xdb27e70dce903053,
>> 0x315efac9cb693387, 0x2d56c54db5da75bf ]
>> dn_blkptr = [
>> {
>> blk_dva = [
>> {
>> dva_word = [ 0x87c9ed7672454887,
>> 0x760f569622246efe ]
>> }
>> {
>> dva_word = [ 0xce26ac20a6a5315c,
>> 0x38802e5d7cce495f ]
>> }
>> {
>> dva_word = [ 0x9241150676798b95,
>> 0x9c6985f95335742c ]
>> }
>> ]
>> None of this looks believable. So, just what is the rootbp in the
>> uberblock_t referring to?
>>
>> thanks,
>> max
>>
>>
>> _______________________________________________
>> zfs-discuss mailing list
>> zfs-discuss@opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>>
>
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
