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.
!DSPAM:476d1d36310541813613882!
