On Thu, Apr 1, 2021 at 4:14 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > Hi all, > > This series creates a new FIEXCHANGE_RANGE system call to exchange > ranges of bytes between two files atomically. This new functionality > enables data storage programs to stage and commit file updates such that > reader programs will see either the old contents or the new contents in > their entirety, with no chance of torn writes. A successful call > completion guarantees that the new contents will be seen even if the > system fails. > > 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 exchange the relevant ranges of the temp file > with the original file. If the updates are aligned with the file block > size, a new (since v2) flag provides for exchanging only the written > areas. Callers can arrange for the update to be rejected if the > original file has been changed. > > 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. > Here is the proposed manual page: > I like the idea of modernizing FIEXCHANGE_RANGE very much and I think that the improved implementation and new(?) flags will be very useful just the way you designed them, but maybe something to consider... Taking a step back and ignoring the existing xfs ioctl, all the use cases that you listed actually want MOVE_RANGE not exchange range. No listed use case does anything with the old data except dump it in the trash bin. Right? I do realize that implementing atomic extent exchange was easier back when that ioctl was implemented for xfs and ext4 and I realize that deferring inode unlink was much simpler to implement than deferred extent freeing, but seeing how punch hole and dedupe range already need to deal with freeing target inode extents, it is not obvious to me that atomic freeing the target inode extents instead of exchange is a bad idea (given the appropriate opt-in flags). Is there a good reason for keeping the "freeing old blocks with unlink" strategy the only option? Thanks, Amir.
