Hi Roch, Roch - PAE wrote: > [EMAIL PROTECTED] writes: > > Roch - PAE wrote: > > > [EMAIL PROTECTED] writes: > > > > Jim Mauro wrote: > > > > > > > > > > Hey Max - Check out the on-disk specification document at > > > > > http://opensolaris.org/os/community/zfs/docs/. >
> > > > 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...). > > > > > > > > > > Max, this might help (zfs_mdcomp_disable) : > > > > http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#METACOMP > > > > > Hi Roch, > > That would help, except it does not seem to work. I set > > zfs_mdcomp_disable to 1 with mdb, > > deleted the pool, recreated the pool, and zdb -uuuu still shows the > > rootbp in the uberblock_t > > to have the lzjb flag turned on. So I then added the variable to > > /etc/system, destroyed the pool, > > rebooted, recreated the pool, and still the same result. Also, my mdb > > shows the same thing > > for the uberblock_t rootbp blkptr data. I am running Nevada build 55b. > > > > I shall update the build I am running soon, but in the meantime I'll > > probably write a modified cmd_print() function for my > > (modified) mdb to handle (at least) lzjb compressed metadata. Also, I > > think the ZFS Evil Tuning Guide should be > > modified. It says this can be tuned for Solaris 10 11/06 and snv_52. I > > guess that means only those > > two releases. snv_55b has the variable, but it doesn't have an effect > > (at least on the uberblock_t > > rootbp meta-data). > > > > thanks for your help. > > > > max > > > > My bad. The tunable only affects indirect dbufs (so I guess > only for large files). As you noted, other metadata is > compressed unconditionaly (I guess from the use of > ZIO_COMPRESS_LZJB in dmu_objset_open_impl). > > -r > > > This makes printing the data with ::print much more problematic... The code in mdb that prints data structures recursively iterates through the structure members reading each member separately. I can either write a new print function that does the decompression, or add a new dcmd that does the descompression and dumps the data to the screen, but then I lose the structure member names in the output. I guess I'll do the decompression dcmd first, and then figure out how to get the member names back in the output... thanks, max _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
