I'm fairly new to all this and I think that is the intended behavior. Also from my limited understanding I believe dedup behavior it would significantly cut down on access times. For the most part though this is such new code that I would wait abit to see where they take it.
On Tue, Nov 3, 2009 at 3:24 PM, Cyril Plisko <cyril.pli...@mountall.com>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 ? > > > -- > Regards, > Cyril > _______________________________________________ > 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
