On Wed, Apr 29, 2020 at 4:46 AM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > This series creates a new log incompat feature and log intent items to > track high level progress of swapping ranges of two files and finish > interrupted work if the system goes down. It then adds a new > FISWAPRANGE ioctl so that userspace can access the atomic extent > swapping feature. With this feature, user programs will be able to > update files atomically by opening an O_TMPFILE, reflinking the source > file to it, making whatever updates they want to make, and then > atomically swap the changed bits back to the source file. It even has > an optional ability to detect a changed source file and reject the > update. > > The intent behind this new userspace functionality is to enable atomic > rewrites of arbitrary parts of individual files. For years, application > programmers wanting to ensure the atomicity of a file update had to > write the changes to a new file in the same directory, fsync the new > file, rename the new file on top of the old filename, and then fsync the > directory. People get it wrong all the time, and $fs hacks abound. > > With atomic file updates, this is no longer necessary. Programmers > create an O_TMPFILE, optionally FICLONE the file contents into the > temporary file, make whatever changes they want to the tempfile, and > FISWAPRANGE the contents from the tempfile into the regular file. That also requires the *readers* to be atomic though, right? Since now the updates are visible to readers instantly, instead of only on the next open()? If you used this to update /etc/passwd while someone else is in the middle of reading it with a sequence of read() calls, there would be fireworks... I guess maybe the new API could also be wired up to ext4's EXT4_IOC_MOVE_EXT somehow, provided that the caller specifies FILE_SWAP_RANGE_NONATOMIC?
