Hi Eric and all,
Eric Schrock wrote:
On Nov 3, 2009, at 6:01 AM, Jürgen Keil wrote:
I think I'm observing the same (with changeset 10936) ...
# mkfile 2g /var/tmp/tank.img
# zpool create tank /var/tmp/tank.img
# zfs set dedup=on tank
# zfs create tank/foobar
This has to do with the fact that dedup space accounting is charged to
all filesystems, regardless of whether blocks are deduped. To do
otherwise is impossible, as there is no true "owner" of a block
It would be great if someone could explain why it is hard (impossible? not a
good idea?) to account all data sets for at least one reference to each dedup'ed
block and add this space to the total free space?
This has some interesting pathologies as the pool gets full. Namely,
that ZFS will artificially enforce a limit on the logical size of the
pool based on non-deduped data. This is obviously something that should
be addressed.
Would the idea I mentioned not address this issue as well?
Thanks, Nils
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
