On Tue, Jan 07, 2020 at 10:16:14AM -0800, Darrick J. Wong wrote: > Yeah. Fixing that (and maybe adding an ioctl to set the FS UUID online) > were on my list for 5.6 but clearly I have to defer everything until 5.7 > because we've just run out of time. > > Uh... I started looking into unifying the ext4 and xfs defrag ioctl, but > gagged when I realized that the ext4 ioctl also handles the data copy > inside the kernel. I think that's the sort of behavior we should /not/ > allow into the new ioctl, though that also means that the required > changes for ext4/e4defrag will be non-trivial. Well, we should eventually end up with a common defrag tool (e.g. in util-linux). We might as well start of with the xfs_fsr codebase for that or whatever suits us best. > The btrfs defrag ioctl also contains thresholding information and > optional knobs to enable compression, which makes me wonder if we should > focus narrowly on swapext being "swap these extents but only if the > source file hasn't changed" and not necessarily defrag? That sounds like the most useful common API. > ...in which case I wonder, can people (ab)use this interface for atomic > file updates? Create an O_TMPFILE, reflink the source file into the > temp file, make your updates to the tempfile, and then swapext the > donor's file data back into the source file, but only if the source file > hasn't changed? Sure.
