On Thu, May 2, 2019 at 1:11 PM Vijay Chidambaram <vijay@xxxxxxxxxxxxx> 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.
