[EMAIL PROTECTED] wrote:
>
> On Fri, 11 Feb 2000 13:25:19 -0500 , "Len Budney" writes:
> > Andre Oppermann <[EMAIL PROTECTED]> wrote:
> > > 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?
>
> FFS with sync metadata (the default) does. I'm not
> sure on FFS/softupdates.
It does also for softupdates. The only case FFS does not guarantee this
is when you mount FFS async.
> > 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.
> >
> > If link() can return success, yet the link itself vanish after a reboot,
> > then mail can be lost. Where does that leave us?
>
> FFS with softupdates honors fsync() calls. I.e. if
> fsync() has returned, the file (both data and
> metadata) is guaranteed to be on the disk.
Exactly. softupdates does NOT change FFS semantics, it's just faster.
> Again, I don't know if the link() call guarantees
> the new link will be on disk. If it doesn't, then
> fsync()ing the directory of the target link should
> flush the link to disk[1].
>
> However, all this discussion is moot if the softupdates
> code preserves the semantics of link() and/or
> rename().
It does.
-snip-
> [1] The update containing the new link should only
> depend on the target of the link being on disk.
> This was provided by the fsync() of the file. Thus,
> fsync()ing the directory should ensure that the link
> is on disk -- i.e. softupdates probably does not
> break fsync() anymore than Linux does.
It beaks fsync() in no way. The only thing softupdates does is it
creates a dependency graph of all outstanding and cached metadata
transactions and ensures that they hit the disk in the right order
to keep the usual FFS semantics we always had. For deeper information
on softupdates and DOW (delayed ordered writes) look at the paper by
Ganger & Patt.
--
Andre
