On Tue, Feb 09, 2010 at 08:26:42AM -0800, Richard Elling wrote:
> >> "zdb -D poolname" will provide details on the DDT size.  FWIW, I have a
> >> pool with 52M DDT entries and the DDT is around 26GB.

I wish -D was documented; I had forgotten about it and only found the
(expensive) -S variant, which wasn't what I was looking for. 

Well, I wish zdb was documented, but in this case I wish -D was
in the usage message, which is all the documentation we get today.

> >>   $ pfexec zdb -D tank
> >>   DDT-sha256-zap-duplicate: 19725 entries, size 270 on disk, 153 in core
> >>   DDT-sha256-zap-unique: 52284055 entries, size 284 on disk, 159 in core
> >> 
> >>   dedup = 1.00, compress = 1.00, copies = 1.00, dedup * compress / copies 
> >> = 1.00

What units are the "size X on disk, Y in core" figures?  It's very
hard to make sense of them, given the vast difference in entries and
small difference in size of the two rows.  One can assume that the
duplicate entries have more block addresses in them and are bigger, I
suppose, but that isn't really enough to explain the gap.   

At least the on disk / in core values give a roughly consistent ratio,
both these and for a pool I have handy here - though I still don't
know what that means.  

> > how do you calculate the 26 GB size from this?
> 
> The exact size is not accounted. I'm inferring the size by looking at the 
> difference 
> between the space used for the (simple) pool and the sum of the file systems 
> under 
> the pool, where the top-level file system (/tank) is empty with mount points, 
> but no 
> snapshots.

Surely there has to be a better way.  If the numbers above don't give
it, then this brings me back to the method I speculated about in a
previous question..

I presume the DDT pool object can be found and inspected with zdb, to
reveal a size.  If the ratio and guesswork interpretation above holds
true, we might derive the in-core memory requirement from there. 

I don't know how to use zdb to do that for objects in general, nor how
to find or recognise the object in question. Could someone who does
please provide some hints?

I will go look at zdb sources, but (without yet having done so) I
suspect that it will just be printing out figures from zfs data
structures, and I will still need help with interpretation. 

--
Dan.

Attachment: pgpcdFZhvT99l.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to