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, 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
dd if=/dev/urandom of=/tank/foobar/file1 bs=1024k count=512
512+0 records in
512+0 records out
cp /tank/foobar/file1 /tank/foobar/file2
cp /tank/foobar/file1 /tank/foobar/file3
cp /tank/foobar/file1 /tank/foobar/file4
/tank/foobar/file4: No space left on device
zfs list -r tank
NAME USED AVAIL REFER MOUNTPOINT
tank 1.95G 0 22K /tank
tank/foobar 1.95G 0 1.95G /tank/foobar
zpool list tank
NAME SIZE USED AVAIL CAP DEDUP HEALTH ALTROOT
tank 1.98G 515M 1.48G 25% 3.90x ONLINE -
--
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--
Eric Schrock, Fishworks http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
