HAMMER cleanup

[Bill Hacker]

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.
						-Matt

Concur. Bigtime.

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 
separately.

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.

Bill Hacker