On 04/26/11 04:47 PM, Erik Trimble wrote:
On 4/25/2011 6:23 PM, Ian Collins wrote:
On 04/26/11 01:13 PM, Fred Liu wrote:
Hmmmm, it seems dedup is pool-based not filesystem-based.
That's correct. Although it can be turned off and on at the filesystem
level (assuming it is enabled for the pool).
Which is effectively the same as choosing per-filesystem dedup. Just
the inverse. You turn it on at the pool level, and off at the filesystem
level, which is identical to "off at the pool level, on at the
filesystem level" that NetApp does.
If it can have fine-grained granularity(like based on fs), that will be great!
It is pity! NetApp is sweet in this aspect.
So what happens to user B's quota if user B stores a ton of data that is
a duplicate of user A's data and then user A deletes the original?
Actually, right now, nothing happens to B's quota. He's always charged
the un-deduped amount for his quota usage, whether or not dedup is
enabled, and regardless of how much of his data is actually deduped.
Which is as it should be, as quotas are about limiting how much a user
is consuming, not how much the backend needs to store that data consumption.
That was the point I was making: quota on deduped usage does not make sense.
I was curious how he proposed doing it the other way!
--
Ian.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
