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.
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
