Adam, So therefore, the best way is to set this at pool creation time....OK, that makes sense, it operates only on fresh data that's coming over the fence. BUT What happens if you snapshot, send, destroy, recreate (with dedup on this time around) and then write the contents of the cloned snapshot to the various places in the pool - which properties are in the ascendancy here? the "host pool" or the contents of the clone? The host pool I assume, because clone contents are (in this scenario) "just some new data"?
-Me On Wed, Dec 9, 2009 at 18:43, Adam Leventhal <a...@eng.sun.com> wrote: > Hi Kjetil, > > Unfortunately, dedup will only apply to data written after the setting is > enabled. That also means that new blocks cannot dedup against old block > regardless of how they were written. There is therefore no way to "prepare" > your pool for dedup -- you just have to enable it when you have the new > bits. > > On Dec 9, 2009, at 3:40 AM, Kjetil Torgrim Homme wrote: > > > I'm planning to try out deduplication in the near future, but started > > wondering if I can prepare for it on my servers. one thing which struck > > me was that I should change the checksum algorithm to sha256 as soon as > > possible. but I wonder -- is that sufficient? will the dedup code know > > about old blocks when I store new data? > > > > let's say I have an existing file img0.jpg. I turn on dedup, and copy > > it twice, to img0a.jpg and img0b.jpg. will all three files refer to the > > same block(s), or will only img0a and img0b share blocks? > > > >
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
