Re: RFC: O_PONIES semantics (well O_REWRITE)

[Jamie Lokier <jamie@shareable.org>]

Rik van Riel wrote:
> The ext4 automatic-fsync-on-rename discussion has shown that
> many applications simply Do It Wrong when it comes to rewriting
> configuration files.

I got the impression ext4 has
automatic-fsync-on-rename-only-if-the-old-file-exists, which is a bit
less reliable.

By the way, the kernel has some generic support for O_SYNC and
O_DSYNC, and generic MS_SYNC mount option.

So I guess it could also have generic support for mount options
"sync_on_rename" and "sync_on_close", instead of only doing it with ext4.

For example, this came up recently on the linux-mtd list which deals
with flash filesystems.  The ext4-like behaviour is being considerd in
a flash filesystem.  So if it's that important, maybe it would be even
better to make it a generic VFS mount option for all filesystems.

> Some of the common failures are:
> - program overwrites the old config file
> - program writes a new file, but forgets to fsync before rename
> - program writes the new file in /tmp, so the rename fails on
>   some systems
> - program writes a new file and fsyncs, but forgets to give the
>   new file the same file ownership, permission and/or extended
>   attributes as the old file

It's also really hard to do those things from shell scripts, so they
are almost never done there.

> Glibc has the advantage of it not being in the kernel, but
> implementing it in-kernel might give us the opportunity for
> performance enhancements, like reducing step (5) to merely
> enforcing ordering between filesystem operations, instead
> of requiring an fsync.

I think the performance enhancement from order-without-sync might be
useful, I'm not sure, but if so not just for this operation, which is
still quite specialised.

-- Jamie