> i am no pro in zfs, but to my understanding there is no original. That is correct. From a semantic perspective, there is no change in behavior between dedup=off and dedup=on. Even the accounting remains the same: each reference to a block is charged to the dataset making the reference. The only place you see the effect of dedup is at the pool level, which can now have more logical than physical data. You may also see a difference in performance, which can be either positive or negative depending on a whole bunch of factors.
At the implementation level, all that's really happening with dedup is that when you write a block whose contents are identical to an existing block, instead of allocating new disk space we just increment a reference count on the existing block. When you free the block (from the dataset's perspective), the storage pool decrements the reference count, but the block remains allocated at the pool level. When the reference count goes to zero, the storage pool frees the block for real (returns it to the storage pool's free space map). But, to reiterate, none of this is visible semantically. The only way you can even tell dedup is happening is to observe that the total space used by all datasets exceeds the space allocated from the pool -- i.e. that the pool's dedup ratio is greater than 1.0. Jeff _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
