Cyril Plisko wrote:
BTW, are there any implications of having dedup=on on rpool/dump ? I
know that the compression is turned off explicitly for rpool/dump.
It will be ignored because when you write to the dump ZVOL it doesn't go
through the normal ZIO pipeline so the deduplication code is never
>>
>> BTW, are there any implications of having dedup=on on rpool/dump ? I
>> know that the compression is turned off explicitly for rpool/dump.
>
> It will be ignored because when you write to the dump ZVOL it doesn't go
> through the normal ZIO pipeline so the deduplication code is never run in
>
Cyril Plisko wrote:
On Thu, Dec 10, 2009 at 12:37 AM, James Lever wrote:
On 10/12/2009, at 5:36 AM, Adam Leventhal wrote:
The dedup property applies to all writes so the settings for the pool of origin
don't matter, just those on the destination pool.
Just a quick related question I’ve not
On Thu, Dec 10, 2009 at 12:37 AM, James Lever wrote:
>
> On 10/12/2009, at 5:36 AM, Adam Leventhal wrote:
>
>> The dedup property applies to all writes so the settings for the pool of
>> origin don't matter, just those on the destination pool.
>
> Just a quick related question I’ve not seen answe
On 10/12/2009, at 5:36 AM, Adam Leventhal wrote:
> The dedup property applies to all writes so the settings for the pool of
> origin don't matter, just those on the destination pool.
Just a quick related question I’ve not seen answered anywhere else:
Is it safe to have dedup running on your rp
> 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,
Adam,
So therefore, the best way is to set this at pool creation timeOK, 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 t
Adam Leventhal writes:
> 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 enabl
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 hav
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 b
10 matches
Mail list logo
