From owner-freebsd-stable@FreeBSD.ORG Sun May 30 02:58:26 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 254E1106566B for ; Sun, 30 May 2010 02:58:26 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C52598FC15 for ; Sun, 30 May 2010 02:58:25 +0000 (UTC) Received: by vws12 with SMTP id 12so3495198vws.13 for ; Sat, 29 May 2010 19:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kNRwDKpd9APfZ2r9OFzanGvePzuuHY9rS58GitQNjQw=; b=jk+waaZCqc2Fy9S4ZlAMls0C9Sybpio+/NTRKzVTKKp/RGX0ztYAxr9tB8qz270yaa 5X4SI3DfC0nSXK/8DTNTufM0M/Sl1x/JIXsJeFtI6cYwwL7w6q7ys1ZJwnj9RtRCrJo4 07Njk7H7mtuO4R7Gzgz8kh4oyfLGp/Pmsl+sA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lya23GRcly8RxgrP1MbV/137p1TQXIdXorNO9nERRmYu8wxxrMnrgvDLhxPSz/IQ/B yWBxfXt8UheVrnbWSoLpek/86ZTISk/11mO51WVzCN0dDXPzx3s7uIZ/CZBHzQZGKNqf GJBmSZh95cOPJXj8AhqUl8v/RZise0Zib1rG8= MIME-Version: 1.0 Received: by 10.229.236.135 with SMTP id kk7mr408429qcb.145.1275188304598; Sat, 29 May 2010 19:58:24 -0700 (PDT) Received: by 10.229.190.83 with HTTP; Sat, 29 May 2010 19:58:24 -0700 (PDT) In-Reply-To: <4C017419.9010909@strauser.com> References: <4C017419.9010909@strauser.com> Date: Sat, 29 May 2010 19:58:24 -0700 Message-ID: From: Garrett Cooper To: Kirk Strauser Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 30 May 2010 02:58:26 -0000 On Sat, May 29, 2010 at 1:07 PM, Kirk Strauser wrote: > I found some nice scripts to regularly snapshot all the filesystems in my > ZFS pool at > http://www.neces.com/blog/technology/integrating-freebsd-zfs-and-periodic-snapshots-and-scrubs > . One thing bothers me, though: I have to intentionally set how many months' > worth of snapshots I want to keep. Too many and I run out of room. Too few > and I lose some of the benefits of easy recovery of deleted data. My > computer is better at bookkeeping than I am, so why not let it? > > I'd propose standardizing on an attribute like org.freebsd:allowautodestroy. > Modify ZFS's disk full behavior to scan for snapshots with that attribute > set and destroy the oldest one, and continue until there's enough free space > to complete a write requests or until out of "expendable" snapshots to > destroy (at which time the normal disk full handler would run). Also run a > daily periodic script to ensure that the free space stays below a > configurable threshold each day so that ZFS isn't constantly butting up > against completely full drives. > > This would take all configuration guesswork out of the equation and would > let me keep as many snapshots as I have space to maintain. If I want to > extend my reach back in time, I can add another drive to the pool and the > rest is handled automatically. At the same time, should I suddenly *want* to > store massive amounts of new data, the snapshots can be easily and > automatically cleared out to make room for the stuff I want to hold. > > What do you think? It seems like this should be pretty easy to implement > without requiring any upstream changes or new FreeBSD-only data structures. > The whole thing could possibly be implemented in userspace, but I don't know > that ZFS has any exception handling callbacks that would make it easy. > > An unused resource is a wasted resource, right? So basically you're saying deal with an LRU snapshot deletion when you reach a certain threshold of free space, type scheme? This might get tricky, but it does lend itself to other systems I suppose (I hate to mention it, but the best one I can think of is Windows' system restore... there might be something else available with OSX's Time Machine). What would be more tricky is when the automated system is filling in a bunch of useless snapshots unnecessarily, but as you'd be providing the snapshot criteria, I suppose that you would know what snapshots you want to save and what ones you want to toss... It's an interesting thought though -- just increases the overall complexity of the system and may only meet one need. Cheers, -Garrett