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
Hi Jim,
Yes, I have tried an objset_phys_t. This is what I am using below in
the example. Either there's some
extra stuff that the on-disk format specification is not saying, or I'm
not picking up the correct blkptr
(though I have tried other blkptr's from the uberblock array following
the nvpair/label section at the
beginning of the disk), or the uberblock_t blkptr is pointing to
something completely different. I am
going to have another look at the zdb code, as I suspect that it must
also do something like what I am
trying to do. Also, I think someone on this list should know what the
uberblock_t blkptr refers to
if it is not an objset_t. I don't have compression or any encryption
turned on, but I am also wondering
if the metadata is somehow compressed or encrypted.
Thanks for the response. I was beginning to think the only people that
read this mailing list are admins...
(Sorry guys, getting zfs configured properly is much more important than
what I'm doing here, but
this is more interesting to me).
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
