From owner-freebsd-stable@FreeBSD.ORG Mon May 31 02:36:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79F5F1065673 for ; Mon, 31 May 2010 02:36:07 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id 36EDF8FC15 for ; Mon, 31 May 2010 02:36:06 +0000 (UTC) Received: from [192.168.1.103] (bas1-toronto09-1279534184.dsl.bell.ca [76.68.36.104]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id o4V2aAfH018156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 May 2010 22:36:11 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Message-Id: <19664824-1B23-4E5F-BC12-BB4D59A9C8AA@ee.ryerson.ca> From: David Magda To: Kirk Strauser In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 May 2010 22:35:59 -0400 References: <4C017419.9010909@strauser.com> <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca> X-Mailer: Apple Mail (2.936) Cc: FreeBSD-STABLE Mailing List Subject: Re: Make ZFS auto-destroy snapshots when the out of space? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 02:36:07 -0000 On May 30, 2010, at 22:17, Kirk Strauser wrote: > For instance, what happens if a disk-full condition occurs 2 minutes > before the cron job would have run that would've averted it? At what > level do you trigger deletions that would both 1) provide enough of > a safety margin that disk-fulls are unlikely, but 2) allow the > snapshots to take advantage of as much storage as possible? What happens now when your UFS file system gets full? :) The situation is no worse than that in the case of a pool filling up, regardless of whether it's because of an abundance of snapshots or simply lots of "regular" user data. > But we have all sorts of daemons that do stuff behind our back. Yes, but they're daemons, not kernel code. As a general rule I like to be able to do a ps(1) on any one of my systems and be able to describe what every single PID does. If it's Amanda, I know what its purpose is; if it would be something called auto-snap(8) or auto-scrub(8) or auto-snap-clean(8) then I'd have to learn what those are. An event framework would certainly be helpful in a general sense (Linux has event(3) AFAIK), and that could certainly be useful for purging snapshots during resource constrained situations. But even if we don't have it, I doubt a fork(2) from cron(8) and a statfs(2) would be onerous on a system. :) > That just scrubs the pools, ie verifies checksums and data > consistency. Yes, I know, it was the general principle I was going after: if you want something periodic to be checked, you should run it from cron/SMF/ launchd/etc.