linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [XFS SUMMIT] Atomic File Updates
@ 2020-04-22 23:45 Darrick J. Wong
  0 siblings, 0 replies; only message in thread
From: Darrick J. Wong @ 2020-04-22 23:45 UTC (permalink / raw)
  To: xfs

Hi everyone,

During lockdown, I've been working on teaching[1] XFS how to swap a range
of extents with a different range of extents in another file in such a
way that we're always guaranteed that the swap operation completes, no
matter how many extents have to be swapped.  This guarantee is durable
evne if the filesystem goes down midway through the operation, since log
recovery will finish the job.

In other words, we finally have a mechanism for userspace programs to
update files atomically without resorting (a) to a pile of fsync and
rename spaghetti or (b) creating an O_TMPFILE and using weird procfs
linkat tricks to wire that into the filesystem.  Better yet, other
programs with open file descriptors will see the new contents
immediately.

So the basic user story is that userspace opens a file and decides to
write to it.  The user program then creates an O_TMPFILE.  If the
program only wishes to update a subset of the file, it can FICLONE the
original file's contents, or it can rewrite the file from scratch.

When the update is finished, the program can fsync the temp file and
then call FISWAPRANGE to commit the changes to the original file.  The
program can supply a [cm]time to the kernel, which can use that to
detect that the original file has changed and that the update should not
be applied.

Note that this is /not/ the hardware-assisted directio atomic writes
that have also been suggested on fsdevel.  That interface (if the
storage vendors ever show up with hardware) only supports atomic writes
on a limited number of possibly discontiguous LBAs, whereas this
software mechanism will work on any size file with any number of blocks.

As a side benefit, this also gives XFS the ability to rebuild xattr and
directory data in a temporary file and cleanly swap the clean contents
over when the entire recreation step has finished.

I haven't yet put this out on fsdevel because I've been a bit busy
putting together XFS summit ideas. :/

--D

[1] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=atomic-file-updates

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-04-22 23:47 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-22 23:45 [XFS SUMMIT] Atomic File Updates Darrick J. Wong

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).