Mike, I believe that ZFS treats runs of zeros as holes in a sparse file, rather
than as regular data. So they aren't really present to be counted for
compressratio.
http://blogs.sun.com/bonwick/entry/seek_hole_and_seek_data
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
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
It is by design. The idea is to report the dedup ratio for the data
you've actually attempted to dedup. To get a 'diluted' dedup ratio
of the sort you describe, just compare the space used by all datasets
to the space allocated in the pool. For example, on my desktop,
I have a pool called
Thank you.
However I think it should be more clearly stated in zpool(1M) perhaps
even referring to compressratio and explaining that this one is
different, plus information as shown below how to get a dedupratio which
is similar in meaning to compressratio.
On 13/12/2009 11:44, Jeff
Hi,
The compressratio property seems to be a ratio of compression for a
given dataset calculated in such a way so all data in it (compressed or
not) is taken into account.
The dedupratio property on the other hand seems to be taking into
account only dedupped data in a pool.
So for example if
