On Mon, Dec 14, 2009 at 3:54 PM, Craig S. Bell <cb...@standard.com> wrote: > I am also accustomed to seeing diluted properties such as compressratio. > IMHO it could be useful (or perhaps just familiar) to see a diluted dedup > ratio for the pool, or maybe see the size / percentage of data used to arrive > at dedupratio. > > As Jeff points out, there is enough data available to calculate this. Would > it be meaningful enough to present a diluted ratio property? IOW, would that > tell me anything than I don't get from simply using "available" as my fuel > gauge? > > This is probably a larger topic: What additional statistics would be > genuinely useful to the admin when there is space interaction between > datasets. As we have seen, some commands are less objective with dedup:
I was recently confused when doing mkfile (or was it dd if=/dev/zero ...) and found that even though blocks were compressed away to nothing, the compressratio did not increase. For example: # perl -e 'print "a" x 100000000' > /test/a # zfs get compressratio test NAME PROPERTY VALUE SOURCE test compressratio 7.87x - However if I put null characters into the same file: # dd if=/dev/zero of=a bs=100000000 count=1 1+0 records in 1+0 records out # zfs get compressratio test NAME PROPERTY VALUE SOURCE test compressratio 1.00x - I understand that a block is not allocated if it contains all zero's, but that would seem to contribute to a higher compressratio rather than a lower compressratio. If I disable compression and enable dedup, does it count deduplicated blocks of zeros toward the dedupratio? -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
