Len Budney wrote:
>
> (This post is still on-topic, but hanging by a thread.)
>
> Magnus Bodin <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 10, 2000 at 11:21:08PM -0500, Len Budney wrote:
> > > ...the reliability impact of soft updates on FFS--giving us a good
> > > example of both a reliable journalled filesystem, and an unreliable
> > > journalled filesystem.
> >
> > Thanks. Yes. Let's make the clarification. FFS with soft updates is NOT a
> > journaling file system.
>
> Thanks for the correction. Do you have a reference for that? I couldn't
> find one.
>
> It is possible to use soft update technology while still maintaining a
> journal of metadata. I assumed, apparently incorrectly, that FFS did
> this. (If the metadata journal has been discarded, I would have thought
> that the filesystem would be different enough to warrant a new name.)
Appearantly you mixed something up here. FFS never did journaling and
neither does softupdates.
> > It DOES NOT MEAN that rename() is no longer an atomic operation in respect
> > to other applications, but if you get a crash between the rename() and the
> > fsync() you cannot be sure that the rename has been done when you come up
> > again.
> >
> > The impact of qmail is however dim to me.
>
> qmail-queue never calls rename; only link. If I'm wrong in assuming
> that your remarks transfer to link, please let me know. With that
> disclaimer, here's how qmail-queue enqueues a message:
>
> 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.
> > Do we have to add extra fsyncs here?
>
> I'm not sure. In your other post (subject: ``fsync semantics''), you
> didn't supply the arguments to fsync.
>
> Is it necessary to open each of queue/mess, queue/intd and queue/todo
> and fsync them? In that case we need three more fsyncs (under FFS with
> softupdates, at least).
NoNoNo! You are wrong for softupdates, it does not need an fsync() on
the directory. Linux EXT2 does need one.
> Does fsyncing an open file descriptor sync not only metadata but hard
> links as well? In that case fsyncing queue/intd/messnum again after
> #6 suffices.
(Hard) links are metadata. On *BSD/SYSV and derivates link() is supposed
to be atomically.
Remember, qmail handles the message like a transactioning system with
roll-forward and roll-back.
--
Andre
