Re: RFC: O_PONIES semantics (well O_REWRITE)

[Andreas Dilger <adilger@sun.com>]

On Jun 10, 2009  21:03 -0400, Rik van Riel wrote:
> The semantics for O_REWRITE would be:
>
> 1) When opening a file O_REWRITE, the file handle points at
>    a freshly allocated, empty file.  The original file is
>    still available to programs that open the file without
>    O_REWRITE.
>
> 2) O_REWRITE can only be used in conjunction with O_WRONLY,
>    because the file descriptor is not associated with the
>    original file (which has data), but with an empty inode.
>
> 3) The code that implements O_REWRITE (kernel?  glibc?)
>    makes sure that:
>    - the new file is on the same filesystem as the original file
>    - the new file is not linked (so it is automatically freed
>      after a process or system crash)
>    - the new file's ownership, permissions and extended attributes
>      match that of the original file
>
> 4) The application that opens a file O_REWRITE is required
>    to rewrite the entire file.

This is all essentially open(O_CREAT|O_TRUNC|O_WRONLY)

> 5) On close(), the code that implements O_REWRITE makes sure that
>    the file is atomically renamed, so that if a system crash happens,
>    the user will see either the old or the new file contents, but
>    never an empty file.

This would be possible if the kernel set the i_size=0, but didn't
send the filesystem the truncate until the file was closed and
being flushed.

> 6) After close(), processes that open the file will get the new
>    content.  Processes that previously opened the file will hold
>    on to the old inode and get old contents.

What is the benefit of (6)?  Of all these semantics this is the
one that would cause the most confusion I think.

> Here are my questions:
>
> - Are these semantics useful for programs that want to replace
>   config (or other) files with new content?
>
> - Are these semantics sane?
>
> - What would be the best place to implement these semantics?

The main question is - would any applications use O_REWRITE in
the first place, or would it just make sense to have a helper
function in glibc like e.g. mktemp that handles the "atomic
update of config file" properly in the first place.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.