Re: [PATCH] 2.4.19-rc1/2.5.25 provide dummy fsync() routine for directories on NFS mounts

[Matthias Andree]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 15 Jul 2002, Patrick J. LoPresti wrote:

> > Postfix is ahead of that: it omits the first fsync() you suggest,
> > because the +x flag, while necessary, is not sufficient to mark the
> > mail as "complete, further processing allowed". The "message file"
> > is a structured file format that has an "end" record at the end of
> > the file.
> 
> This is not sufficient!  Data writes are NOT guaranteed to be ordered.
> It is permissible for the file system to flush the first and last
> block of a file to disk BEFORE flushing the middle.  You either need
> the double fsync() or you need a checksum in the file; simple markers
> are not enough to make a real guarantee.  And MTAs should be making
> real guarantees!

*shrug* sounds plausible. Isn't this a case for data=ordered? The data
blocks are there before the +x flag is committed, or am I mistaken here?

However, as Postfix by default imposes chattr +S on its queue, nothing
is lost except performance. Or is not even chattr +S sufficient here
with single fsync()?

> Failing to call fsync() at all (i.e., failing to commit metadata
> updates) is what can recreate dead files.

Doesn't apply.

> > Postfix' local(8) daemon additionally relies on rename(2) being
> > synchronous (in Maildir delivery), it does not fsync() after rename.
> > OTOH, the file is completely in Maildir/tmp/somename, so it's not
> > really lost, just invisible.
> 
> No, it is lost, because the file's creation is not guaranteed to have
> happened at all!  (Well, depending on the file system and the
> semantics.  I think I need to write this up more clearly.)

Euhm, assume chattr +S on Maildir/tmp/ -- this is where the file is
created. Now, a rename() is issued, from a chattr +S (sync) directory to
a chattr -S directory. Is this safe or will the destination directory
also have to be +S? If so, it might be very useful performance-wise to
NOT have files inherit the +S flag.

> As I said, the issue is what descriptors they should call fsync() on.
> On Linux, fsync() on a file's descriptor will commit the file's
> contents; a second fsync() on the containing directory's descriptor
> will commit the rename()/link().

MTA authors will probably not go this length.

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9MzWmFmbjPHp/pcMRApLEAJ9B5m5b5ith6jkgaR5kt9oG2/AvAACfe0Vc
32OZjmHKYclz9JlB9kjUW+M=
=grP2
-----END PGP SIGNATURE-----