看板 FB_stable 關於我們 聯絡資訊
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-unsubscribe@freebsd.org"