Eric Schrock wrote:
On Nov 3, 2009, at 12:24 PM, 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 ?
Please read my response before you respond. What do you think "this is
obviously something that should be addressed" means? There is already a
CR filed and the ZFS team is working on it.
We have a fix for this and it should be available in a couple of days.
- George
- Eric
--
Regards,
Cyril
--
Eric Schrock, Fishworks
http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
