A quick and easy performance improvement

[Furnish, Trever G]

> -----Original Message-----
> From: mailscanner-bounces at lists.mailscanner.info 
> [mailto:mailscanner-bounces at lists.mailscanner.info] On Behalf 
> Of Alex Neuman van der Hans
> Richard Lynch wrote:
> > So, we split / and /var (and others).  I think all of our 
> unix systems 
> > are that way.  Is this a bad practice?
> > -- Rich
> >
> 
> It isn't. It's just *traditional*. You could set up processes 
> that let you know *beforehand* that your rootfs is getting filled up.
> 
> And you can always log on using a rescue CD, unless it's 
> impractical for geographic reasons, for example.

Setting up alarms for filling filesystems won't help you out if they
fill too quickly to catch.  Log rotation and space-monitoring aren't
sufficient protection from a filled /.

With MailScanner typically also running as root, the feature of many
systems where a certain number of process table entries and file-system
blocks are reserved for the root user to use in case of a crash also
won't help.

I appreciated the original post -- I had never really thought about the
increase in io time caused by separate filesystems.  But on the other
hand I never let applications write to / -- to my traditional way of
thinking, that's broken behavior.  They can write to /var, /tmp, /home,
or whatever fs/directory has been set up for them, but never to /, /usr,
/bin, or /etc.  In some Oses these filesystems are even mounted
read-only.

Besides avoiding disk space starvation on /, I also use separate
filesystems because sometimes I make heavy use of ACLs, which can cause
other headaches.  I try to restrict the usage of ACLs as much as
possible, so only those filesystems that need them have them.

I do like the idea of holding the bayes files in ram -- but Julian's
suggestion that a simple cp command is sufficient for copying that
database seems hard to believe -- seems likely that would lead to a
corrupted database that wouldn't be useful for recovery later.  I would
assume you need to stop MailScanner before copying the file.  And since
we're talking about tmpfs, "recovery" will need to happen after every
server restart, so it's not an infrequent thing.