> Also if you write metadata first then you risk delivering email to
> the wrong person instead.
The MTAs do this:
Open temp file
Write to temp file
fsync() temp file
rename() temp file into mail spool
indicate success to remote MTA
As long as rename() does not return until the metadata are committed,
this should be a reliable delivery mechanism. After a crash, you
might end up with the temp file still there, or with the file having a
link count of two (temp file and spool file). But you can clean up
all of this at boot time; if the temp file is gone and the spool file
is present, then the transaction was completed.
(Yes, you might not have returned the success code to the remote MTA,
but that just means you might do a double delivery. That is an
acceptable failure mode; corrupting, losing, or misdirecting mail is
not.)
How does this scheme "risk delivering mail to the wrong person
instead"?
If you have metadata journalling, all you need for this algorithm to
work is to have rename() write to the journal before returning. Is
this true for any of the current journalling file systems on Linux?
- Pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/