By the way, to give you an idea of the speed of the i-ram drive with the
XFS file system we tar-zipped the entire /usr directory into an 811MB
archive. It took 54 seconds to untar-unzip it on a 4GB I-Ram drive and 141
seconds on a Seagate 750 GB SATA drive with the ext3 filesystem in the same
machine. The CPU is a Core-Duo 6400 with 4GB RAM.
Straight file copies are even faster. Duplicating the same 811MB archive on
the I-Ram took 13 seconds on the I-Ram drive and 43 seconds on the Seagate.
My plan is to use the I-RAM for the following directories;
var/qmail/queue
var/qmail/simscan
var/log
maybe /tmp
let me know if you guys think of any other directories that would benefit
from the speedup.
Also, since the i-ram's battery backup only lasts a few hours we added some
startup scripts to rc.local that try mounting the i-ram and then test for
the existence of some key files. If they don't exist or the i-ram can't be
mounted we then we assume the RAM got erased and use parted to re-create
the partitions and mkfs to add the xfs filesystem. Then we mount the i-ram
drive and copy over and untar the directories that we backed up upon
shutdown (and also backup every few hours).
I think this approach should substantially speedup the mailserver and allow
it to handle greater capacity.
At 09:20 AM 12/22/2007, you wrote:
Ed McLain wrote:
<snip> As for recoveries after a hardware failure, I've only had to do 3
or 4. On one of them we had a buggy version of xfs_repair, and that
caused some weirdness, but we had done a full dd before the restore to a
secondary disk.. After upgrading xfs_repair we got back everything with
no corruption that we could find.. Now, that's not to say that a man page
didn't have null's in it, but everything we wanted was there and in tact.
<snip>
Man pages? You had existing files corrupted? Now that is something I have
not had with ext3. As for XFS, I did lose one filesystem but I cannot pin
it down to XFS code with certainty because that happened after a crash
although I have not lost any ext3 filesystem due to a crash yet.
In any case, my previous mail was about files that were created just prior
to a crash or a power cut, not existing files. Existing files should not
get corrupted. If a filesystem cannot guarantee integrity of existing
files both in a data and metadata sense, then I'd say that is a candidate
for 'untouchable'. When you are dealing with a mail queue, as the OP was
asking about, you do want data integrity because once the mail has been
queued, the sending side will deleted its copy as you have now assumed
responsibility for delivery.
This really means that only filesystems that do full journaling can meet
such a criteria. If you do not mind losing whatever was very recently
queued in the event of a crash/power cut, then go for XFS.
Best Regards,
Jeff Koch, Intersessions
!DSPAM:476d7f49310544027043058!
