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.
> 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.
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().
--
Chris Mikkelson | If you throw your bread upon the waters, it shall come
[EMAIL PROTECTED] | back threefold, but only if you are willing to throw the
| recipe upon the waters as well... -- Terry Lambert
[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.
