Re: [TOPIC] Extending the filesystem crash recovery guaranties contract

[Amir Goldstein <amir73il@gmail.com>]

On Thu, May 2, 2019 at 1:11 PM Vijay Chidambaram <vijay@cs.utexas.edu> wrote:
>
> Thank you for driving this discussion Amir. I'm glad ext4 and btrfs
> developers want to provide these semantics.
>
> If I'm understanding this correctly, the new semantics will be: any
> data changes to files written with O_TMPFILE will be visible if the
> associated metadata is also visible. Basically, there will be a
> barrier between O_TMPFILE data and O_TMPFILE metadata.

Mmm, this phrasing deviates from what I wrote.
The agreement is that we should document something *minimal*
that users can understand. I was hoping that this phrasing meets
those requirements:

""The filesystem provided the guaranty that after a crash, if the linked
 O_TMPFILE is observed in the target directory, than all the data and
 metadata modifications made to the file before being linked are also
 observed."

No more, no less.

>
> The expectation is that applications will use this, and then rename
> the O_TMPFILE file over the original file. Is this correct? If so, is
> there also an implied barrier between O_TMPFILE metadata and the
> rename?

Not really, the use case is when users want to create a file to apear
"atomically" in the namespace with certain data and metadata.

For replacing an existing file with another the same could be
achieved with renameat2(AT_FDCWD, tempname, AT_FDCWD, newname,
RENAME_ATOMIC). There is no need to create the tempname
file using O_TMPFILE in that case, but if you do, the RENAME_ATOMIC
flag would be redundant.

RENAME_ATOMIC flag is needed because directories and non regular
files cannot be created using O_TMPFILE.

>
> Where does this land us on the discussion about documenting
> file-system crash-recovery guarantees? Has that been deemed not
> necessary?
>

Can't say for sure.
Some filesystem maintainers hold on to the opinion that they do
NOT wish to have a document describing existing behavior of specific
filesystems, which is large parts of the document that your group posted.

They would rather that only the guaranties of the APIs are documented
and those should already be documented in man pages anyway - if they
are not, man pages could be improved.

I am not saying there is no room for a document that elaborates on those
guaranties. I personally think that could be useful and certainly think that
your group's work for adding xfstest coverage for API guaranties is useful.

Thanks,
Amir.