On Thu, May 2, 2019 at 10:30 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Thu, May 02, 2019 at 01:39:47PM -0400, Amir Goldstein wrote: > > > 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? > > In the case of O_TMPFILE, the file can be brought into the namespace > using something like: > > linkat(AT_FDCWD, "/proc/self/fd/42", AT_FDCWD, pathname, AT_SYMLINK_FOLLOW); > > it's not using rename. > > To be clear, this discussion happened in the hallway, and it's not > clear it had full support by everyone. After our discussion, some of > us came up with an example where forcing a call to > filemap_write_and_wait() before the linkat(2) might *not* be the right > thing. Suppose some browser wanted to wait until a file was fully( > downloaded before letting it appear in the directory --- but what was > being downloaded was a 4 GiB DVD image (say, a distribution's install > media). If the download was done using O_TMPFILE followed by > linkat(2), that might be a case where forcing the data blocks to disk > before allowing the linkat(2) to proceed might not be what the > application or the user would want. > > So it might be that we will need to add a linkat flag to indicate that > we want the kernel to call filemap_write_and_wait() before making the > metadata changes in linkat(2). > Agreed. > > 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. > > I think there's much less consensus about this. Again, most of this > happened in a hallway conversation. > OK. we can leave that one for later. Although I am not sure what the concern is. If we are able to agree and document a LINK_ATOMIC flag, what would be the down side of documenting a RENAME_ATOMIC flag with same semantics? After all, as I said, this is what many users already expect when renaming a temp file (as ext4 heuristics prove). I would love to get Dave's take on the proposal of LINK_ATOMIC/ RENAME_ATOMIC, preferably before the discussion wanders off to an argument about what SOMC means... Thanks, Amir.
