Date: Sun, 30 May 2010 21:17:56 -0500 From: Kirk Strauser <kirk@strauser.com> To: David Magda <dmagda@ee.ryerson.ca> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Make ZFS auto-destroy snapshots when the out of space? Message-ID: <F5E2E18E-A870-4600-9D4C-D0BE9BF68CF1@strauser.com> In-Reply-To: <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca> References: <4C017419.9010909@strauser.com> <4632C12D-2B1E-4073-B2C9-E9D15C212EF1@ee.ryerson.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 30, 2010, at 7:33 PM, David Magda wrote: > Why not simply have a script that runs and checks for pool usage and > then deletes snapshots with that attribute if necessary? Why do you > need to have have it built into ZFS? That's certainly possible and I suspect most people here could knock that out in about 20 minutes. The problem is that you get into all kinds of race conditions and manual bookkeeping. 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? > IMHO this shouldn't be built into the file system. You have one > script to automatically generate snapshots, and another to monitor > usage and delete old ones. I'm not opposed to that approach at all, with the exception that I'd like for the deletion script to be triggerable from the filesystem. And as I said in another post, I'd like that as a generic cross- filesystem feature. Maybe you'd like a UFS-based /tmp/log directory that a certain daemon fills with rotating logfiles, and you'd like a script to automatically delete the oldest one whenever the filesystem fills. Or maybe it'd be nice to get an email when /var is over 90% full? I can think of a lot of uses for that mechanism other than the specific case of destroying ZFS snapshots. > Good summary in this post: > > http://mail.opensolaris.org/pipermail/zfs-discuss/2006-May/ > 002313.html I disagree with the cons of the summary. It's made to sound like ZFS would be responsible for making tough decisions about what to keep and discard, when that could really be simplified to deleting the snapshot with the lowest integer value of a certain attribute and re-trying failed writes until either the write succeeds or there are no more filesystems to delete. Then have a regular cron job - probably even the one that creates the snapshots in the first place - that assigns priorities appropriates. It would require a small amount of kernel could, but it could be very simple code with no decision-making responsibilities. > Generally I don't think this is the "Unix Way". I don't want my > kernel doing stuff behind my back. But we have all sorts of daemons that do stuff behind our back. I have a nightly Amanda daemon that decides what and how much to back up and when to overwrite old backups. The difference, as I see it, is that in the ZFS case the kernel would have a very small amount of extra work to do. That kernel code would eliminate the need for a lot of potentially-flakey userspace code. > There's already an useful creation tool for OpenSolaris: > > http://src.opensolaris.org/source/xref/jds/zfs-snapshot/ That's actually the easy part. From the scripts I downloaded at the link in the original post, I have that running in production on my system today. > There's also an auto-scrub script: > > http://blogs.sun.com/constantin/entry/new_opensolaris_zfs_auto_scrub > That just scrubs the pools, ie verifies checksums and data consistency. -- Kirk Strauser
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F5E2E18E-A870-4600-9D4C-D0BE9BF68CF1>