[This is an on-going experiement but NONE of the following can hurt:]
Recently on a ~1500 user Linux box that I support, we have had major EXT2 filesystem corruptions on two seperate occasions. I then emailed several people about this and here are two replies I received:
From Warlock:
--
Personally, I have cron run `sync' in the background every 10 minutes
or so and, averaged over any reasonable period of time, . . . (I have been
doing this) Forever. . . . Doing a sync in the background every so often
(or between packages) pretty much fixed that problem. Now everything is
much more stable, but the principle still holds.
I think the double-sync (old-timers use a triple, but our computers and
peripherals were slower back then) (: is for when you want to *shut down*
(or reboot) and risk something very unclean. Even if you type `sync',
that isn't guaranteed. It basically tells the kernel to clean up and then
returns, but the actual process isn't finished by the time sync finishes.
I think the logic was that a double-sync might block until the first
sync was finished, and a triple-sync was just there to but time for
the hard drive to finish writing out anything (disconnected SCSI drive,
for example). I'm sure actually waiting 5-6 seconds after you typed the
first sync would be just as good 90% of the time, but you know humans. (:
--
So, to implement this:
Redhat:
* edit /etc/crontab and append:
--
0,10,20,30,40,50 * * * * root run-parts /etc/cron.10min
--
* Now create the dir /etc/cron.10min
--
mkdir /etc/cron.10min
--
* create the simple file /etc/cron.10min/re-sync
--
sync
--
* Make it executable:
--
chmod 700 /etc/cron.10min/re-sync
--
* That's it. Cron will notice the changes and reload * automatically.
Slackware:
* edit /var/spool/cron/crontabs and append:
--
0,10,20,30,40,50 * * * * root run-parts sync
--
* That's it. Cron will notice the changes and reload * automatically.
From the Yashy-Hack list:
--
Linux ext2 filesystems normally run asynchronously. While this makes them
faster, it also makes them somewhat less reliable, especially on systems with
long uptimes. If you're running a production machine (ie that people are
depending on), you can make filesystems run in synchronous mode by adding the
flag 'sync' to the options section in /etc/fstab - right now that section
likely says 'defaults', or maybe one of the quota options. The filesystems
will be slower, but they'll also be more reliable.
<IMHO>
This is one reason I personally prefer FreeBSD for servers, though I use Linux
for my router and notebook, and frequently for workstations. The BSD ufs
filesystem, which defaults to synchronous operations, is in my experience
more robust for long uptimes on heavily used systems.
>From the FreeBSD mount manpage:
async All I/O to the file system should be done asynchronously.
This is a dangerous flag to set, and should not be used
unless you are prepared to recreate the file system
should your system crash.
</IMHO>