From owner-freebsd-fs@FreeBSD.ORG Thu Jul 4 11:09:23 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 107B5BC4 for ; Thu, 4 Jul 2013 11:09:23 +0000 (UTC) (envelope-from feenberg@nber.org) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by mx1.freebsd.org (Postfix) with ESMTP id C37241EE5 for ; Thu, 4 Jul 2013 11:09:22 +0000 (UTC) Received: from nber2.nber.org (nber2.nber.org [66.251.72.72]) by mail2.nber.org (8.14.4/8.14.4) with ESMTP id r64B9DKA049957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Jul 2013 07:09:14 -0400 (EDT) (envelope-from feenberg@nber.org) Date: Thu, 4 Jul 2013 07:09:13 -0400 (EDT) From: Daniel Feenberg To: Jeremy Chadwick Subject: Re: EBS snapshot backups from a FreeBSD zfs file system: zpool freeze? In-Reply-To: <20130704010815.GB75529@icarus.home.lan> Message-ID: References: <6488DECC-2455-4E92-B432-C39490D18484@dragondata.com> <871u7g57rl.wl%berend@pobox.com> <87mwq34emp.wl%berend@pobox.com> <20130703200241.GB60515@in-addr.com> <87k3l748gb.wl%berend@pobox.com> <20130703233631.GA74698@icarus.home.lan> <87d2qz42q4.wl%berend@pobox.com> <20130704010815.GB75529@icarus.home.lan> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20130704 #10503464, check: 20130704 clean Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 11:09:23 -0000 On Wed, 3 Jul 2013, Jeremy Chadwick wrote: > scripts. > > Also, because nobody seems to warn others of this: if you go the > ZFS route on FreeBSD, please do not use features like dedup or > compression. I can expand more on this if asked, as they have > separate (and in one case identical/similar) caveats. (I'm always > willing to bend on compression as long as the user knows of the one > problem that still exists today and feels it's okay/acceptable) > Please expand on the problem with compression - we have a lot of very large, very "fluffy" datasets that compress down about 90% (and are accessed in pure sequential order) so compression is very attractive to us. dan feenberg NBER