Cyril Plisko 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, and the fact that it may
or may not be deduped is often beyond the control of a single filesystem.
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.
Eric,
Many people (me included) perceive deduplication as a mean to save
disk space and allow more data to be squeezed into a storage. What you
are saying is that effectively ZFS dedup does a wonderful job in
detecting duplicate blocks and goes into all the trouble of removing
an extra copies and keep accounting of everything. However, when it
comes to letting me use the freed space I will be plainly denied to do
so. If that so, what would be the reason to use ZFS deduplication at
all ?
c'mon it is obviously a bug and not a design feature.
(it is I hope/think that is the case)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
