DragonFly kernel List (threaded) for 2008-10
Re: HAMMER cleanup
Matthew Dillon wrote:
Generally speaking I think hammer cleanup should only be automated
to the extent of being run as an overnight cron job.
I would prefer *not* to run hammer cleanup on boot as doing so just
hands us the same problem that background fsck has... it generates a
lot of disk I/O just at the wrong time. Even though the cleanup runs
for a limited period of time I still don't want it to run at boot.
Booting and shutdown are also the most dangerous times for disk
operations, mostly for laptops but also to some extent for desktops
and servers. These are the times where users try new configurations,
new kernels, where power fluctuations might be powering on a machine
or a UPS might be trying to shut it down. It is during these periods
when bad things are most likely to happen. We don't want to run
hammer cleanup during these periods.
I would like to keep a solution for laptops separate from the solution
for desktops. For desktops running overnight would do the trick. As
an alternative the cron can run it hourly... 'hammer cleanup' keeps track
of the time itself and by default will only do major work once a day,
even if run hourly. I dunno how far we should go for the 2.2 release.
Certainly it should at least be run overnight.
Laptops might need a 'cleanup' button. I just don't know when the best
time to run hammer cleanup would be, or for how long. Desktops might
make do with an hourly poke.
JFWIW, we do NOT mount really large arrays in fstab. Nor start the
services that need them right away.
We leave both of those to scripts that run later - after the 'core'
services have gone multi.
We also do not use background fsck'ing, preferring to take the time to
complete that task BEFORE anything wants to access the storage involved.
If undamaged, a fast boot is a welcome windfall. But the ocasisonal dlay
is paid back by assurance that the media is fully ready to use before
services start trying to access it.
I speak of older technology, (UFS with HW RAID, atacontrol or gmirror).
but HAMMER is likely to fall into a similar category. Big drives,
potential longish time needed to do the <whatever>.
As it is *critical* to us to have a box responding to ssh ASAP after a
boot, AND NOT 'hung' at a point that may not even be resolvable w/o
hands-on at a console as much as 12,000 miles away, it has proven
invaluable to keep the basics lean and mean, mount the heavy artillery
Likewise, when it is an R&D box two *feet* away, it is easy to control
how much of just what needs the full monty at each reboot.
JM2CW, but a clean separation of basic boot and full-production has
saved R azz many times over.