--- On Mon, 9/24/12, Richard Elling <richard.ell...@gmail.com> wrote:

I'm hoping the answer is yes - I've been looking but do not see it ...

none can hide from dtrace!# dtrace -qn 'dsl_dataset_stats:entry {this->ds = 
(dsl_dataset_t *)arg0;printf("%s\tcompressed size = %d\tuncompressed 
size=%d\n", this->ds->ds_dir->dd_myname, 
this->ds->ds_phys->ds_uncompressed_bytes)}'openindiana-1   compressed size = 
3667988992    uncompressed size=3759321088
[zfs get all rpool/openindiana-1 in another shell]
For reporting, the number is rounded to 2 decimal places.
Ok.  So the dedupratio I see for the entire pool is
"dedupe ratio for filesystems in this pool that have dedupe
enabled" ... yes ?

Thank you - appreciated.

Doesn't that mean that if I enabled dedupe on more than one filesystem, I can 
never know how much total, raw space each of those is using ?  Because if the 
dedupe ratio is calculated across all of them, it's not the actual ratio for 
any one of them ... so even if I do the math, I can't decide what the total raw 
usage for one of them is ... right ?

Correct. This is by design so that blocks shared amongst different datasets 
canbe deduped -- the common case for things like virtual machine images.

Ok, but what about accounting ?  If you have multiple deduped filesystems in a 
pool, you can *never know* how much space any single one of them is using ?  
That seems unbelievable...

Ok - but from a performance point of view, I am only using
ram/cpu resources for the deduping of just the individual
filesystems I enabled dedupe on, right ?  I hope that
turning on dedupe for just one filesystem did not incur
ram/cpu costs across the entire pool...

It depends. -- richard

Can you elaborate at all ?  Dedupe can have fairly profound performance 
implications, and I'd like to know if I am paying a huge price just to get a 
dedupe on one little filesystem ...

Thanks again.
zfs-discuss mailing list

Reply via email to