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.
e.g.
A, B, C, & D all have 100Mb of data in the pool, with dedup on.
20MB of storage has a dedup-factor of 3:1 (common to A, B, & C)
50MB of storage has a dedup factor of 2:1 (common to A & B )
Thus, the amount of unique data would be:
A: 100 - 20 - 50 = 30MB
B: 100 - 20 - 50 = 30MB
C: 100 - 20 = 80MB
D: 100MB
Summing it all up, you would have an actual storage consumption of 70
(50+20 deduped) + 30+30+80+100 (unique data) = 310MB to actual storage,
for 400MB of apparent storage (i.e. dedup ratio of 1.29:1 )
A, B, C, & D would each still have a quota usage of 100MB.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
