On Wed, 2003-07-30 at 21:43, Yusuf Goolamabbas wrote:
> Wietse's response to Steve Lord's reply
Comments below, but why someone has to relay stuff back and forth like
this I have no idea.
> ----- Forwarded message from Wietse Venema <wietse@xxxxxxxxxxxxx> -----
> Subject: Re: XFS semantics for postfix queues
> To: Yusuf Goolamabbas <yusufg@xxxxxxxxxxxx>
> Date: Wed, 30 Jul 2003 22:02:36 -0400 (EDT)
> Cc: postfix-users@xxxxxxxxxxx
> From: wietse@xxxxxxxxxxxxx (Wietse Venema)
> Postfix requires that fsync() updates the directory AND file before
> it returns.
Postfix seems to be a very demanding program ;-)
> Postfix with maildir also requires that link() completes all updates
> before it returns.
> Postfix requires that rename() updates directories safely so that
> one instance of the file will always exist, even if the system
> should crash in the middle of the operation. With old ext2fs the
> file could end up in lost+found, this is not acceptable.
The way to think about the xfs transaction system is that time rolls
backwards after a crash. A file being renamed will either be in its
old location or the new one - it will not be MIA. And if you perform
a sequence of operations on a file one after another, then after a
crash you will get ALL of the operations upto some point, and none of
the ones after that point. If you want to know that something is on
disk and safe from crash then:
o fsync on a file will flush the log upto at least the last transaction
involving that file - from the above, this means a rename would be
safe on disk.
o fsync on a dir will work too.
> The text below does not confirm that rename()/link() work as
> required. It would be incorrect to assume that every rename()/link()
> operation is followed by fsync().
Hmm, and the question I was asked was not this question, but never mind.
I am pretty sure XFS is doing all the right things here.