Len Budney wrote:
>
> Andre Oppermann <[EMAIL PROTECTED]> wrote:
> > Len Budney wrote:
> > >
> > > 1. Create a file in a temporary directory (queue/pid). It's inode
> > > becomes the message number (say 457).
> > > 3. Link the tempfile to queue/mess/457.
> > > 4. Write the message to queue/mess/457 (via the open file descriptor
> > > in queue/pid). fsync().
> > > 5. Create queue/intd/457, and write the envelope to the file. fsync().
> > > 6. link queue/intd/457 to queue/todo/457.
> > >
> > > If the link in #6 succeeds, qmail-queue will return success. If the link
> > > in queue/todo later vanishes, then so does the mail message.
> >
> > And should be resent later by the sending MTA because qmail did not
> > say "250 ok". Transaction not completed, roll-back.
>
> I'm not sure if we're communicating. Does FFS offer the guarantee that
> when link() succeeds, the hard link exists on the physical disk?
Yes.
> If not, then you are incorrect. When the link in #6 above succeeds,
> qmail-queue returns success. qmail-smtp interprets that as success,
> and returns "250 ok". The client interpets that as success, and
> discards the message. All of this occurs if link() returns success.
I know.
> If link() can return success, yet the link itself vanish after a reboot,
> then mail can be lost. Where does that leave us?
qmail is written for FFS semantics. EXT2 does NOT guarantee these
semantics, eg. the link() returns as soon as the link is done in
the file system cache. EXT2 writes metadata every 30s by default to
the disk. With EXT2 you need to fsync() the directory to get the
metadata (the link) onto the disk.
--
Andre
