Re: intermediate summary of ext3-2.4-0.9.4 thread

[Alexander Viro]

On Fri, 3 Aug 2001, Matthias Andree wrote:

> I did not say that open() is to be synchronous. I did not write ANYTHING
> of fsync()ing directories, I'm trying to get rid of this requirement.
> 
> Thus, if the kernel does rename/link synchronously, you'd never ever
> fsync() a directory. To synch a filename to disk, you'd just fsync() the
> filedescriptor (with a SUS compliant system, that is, i. e. ext3 or
> reiserfs, but not ext2).
> 
> Now, if someone opens a temporary file, and nukes it later -- unlink()
> --, and doesn't want it visible, he never calls fsync() for the file.
> 
> However, if some other process then fsync()s the directory, you start
> synching the temporary file dirent -> unnecessary, is nuked later on
> with an unlink().
> 
> That's why fsync() on the directory is on no account the minimum work.

Show the amount of extra traffic from MTA doing explicit fsync() on parent
vs. kernel doing rename() and link() synchronous.  Unless you can do that
you are not going to convince anybody.  And no, arguments along the lines
"but DJB ain't gonna apply such patches" will not fly.  Maintaining such
patches is not a problem.  In other words, put up or shut up.  It's not
like it was hard to gather such statistics.

If you can show noticable traffic increase - you've got a decent argument.
If not - stop wasting the bandwidth, this thread had been going with no
new contents added for quite a while.