Hi Darrick,
I should have mentioned this earlier, but for several years XFS developer
Christoph Hellwig has been working on a feature inspired by the FAST 2015
paper. My HP colleagues and I met Christoph at FAST 2015 and he expressed
interest in doing something similar in XFS. Since then he has reported
doing a considerable amount of work toward that goal, though I don't know
the current state of his efforts.
I'm just pointing out a possible connection between the "atomic file
commits" described below and Christoph's work; I don't know if the
implementations are similar, but to an outsider it sounds like they aspire
to serve the same purpose: Enabling applications to efficiently evolve
files from one well-defined state to another atomically even in the
presence of failure.
Regardless of how and by whom this goal is achieved, folks like Suyash and
I eagerly await the results.
May the Force be with you!
-- Terence
On Mon, 19 Dec 2022, Darrick J. Wong wrote:
...
<cough> The bits needed for atomic file commits have been out for review
on fsdevel since **before the COVID19 pandemic started**. It's buried
in the middle of the online repair featureset.
Summary of the usage model:
fd = open(sourcefile...)
tmp_fd = open(..., O_TMPFILE)
ioctl(tmp_fd, FICLONE, fd); /* clone data to temporary file */
/* write whatever you want to the temporary file */
ioctl(fd, FIEXCHANGE_RANGE, {tmp_fd, file range...}) /* durable commit */
close(tmp_fd)
True, this isn't an ephemeral file -- for such a thing, we could just
duplicate the in-memory data fork and never commit it to disk. But that
said, I've been trying to get the parts I /have/ built merged for three
years.
I'm planning to push the whole giant thing to the list on Thursday.
--D
