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



[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

Reply via email to