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