On Tue, Dec 8, 2009 at 22:54, Jeff Bonwick <jeff.bonw...@sun.com> wrote:
> > 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, Thomas, Ed & Michael; Thank you all for assisting in the education of a n00bie in this most important ZFS feature. I *think* I have a better overall understanding now. This list is a resource treasure trove! I hope I'm able to acquire sufficient knowledge over time to eventually be able to contribute help to other newcomers. Regards & Thanks for all the help, -Me
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
