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;


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


Reply via email to