EBS snapshot backups from a FreeBSD zfs file system: zpool freeze?

[Steven Hartland]

----- Original Message ----- 
From: "Jeremy Chadwick" <jdc at koitsu.org>
To: "Steven Hartland" <killing at multiplay.co.uk>
Cc: "Berend de Boer" <berend at pobox.com>; "freebsd-fs" <freebsd-fs at freebsd.org>
Sent: Thursday, July 04, 2013 9:22 AM
Subject: Re: EBS snapshot backups from a FreeBSD zfs file system: zpool freeze?


> On Thu, Jul 04, 2013 at 09:06:57AM +0100, Steven Hartland wrote:
>> ----- Original Message ----- From: "Berend de Boer"
>> <berend at pobox.com>
>> Jeremy>   Also, because nobody seems to warn others of this: if
>> Jeremy> you go the ZFS route on FreeBSD, please do not use
>> Jeremy> features like dedup or compression.
>> 
>> While dedup is memory and sometimes cpu hungry, so HW spec
>> should be considered before using it, compression is not so
>> and I've not seen any valid reason not to use it should it
>> fit your uses.
>> 
>> We actually use compression extensivily here and we've
>> had nothing but positive results from it so sounds like
>> FUD to me.
> 
> The problem with the lack of separate and prioritised write threads for
> dedup and compression, thus causing interactivity stalls, is not FUD,
> it's fact.  I explained this in the part of my reply to Berend which you
> omitted, which included the proof and acknowledgement from folks who
> are in-the-know (Bob Friesenhahn).  :/  Nobody has told me "yeah that
> got fixed", so there is no reason for me to believe anything has
> changed.

Do you have an links to the discuss on this Jeremy as I'd be intereted
to read up on the this when I have some spare time?

> If a person considering use of compression on FreeBSD ZFS doesn't mind
> that problem, then by all means use it.  It doesn't change the fact that
> there's an issue, and one that folks should be made aware of up front.
> It's not spreading FUD: it's spreading knowledge of a certain behaviour
> that differs between FreeBSD and Solaris/Illumos.  The issue is a
> deal-breaker for me; if it's not for you, great.

Sounds like it could well be use case based then, as we've not had any
problems compression causing interactively problems. Quite the opposite
in fact, the reduced physical IO that compression results in improved
interactivity.

So I guess its like everything, one size doesn't fit all, so temporing
statements about blanket avoiding the these features seems like the
way to go :)

    Regards
    Steve




    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster at multiplay.co.uk.