Thread (138 messages) flat view 138 messages, 9 authors, 2022-03-10

Re: [PATCH 2/2] core.fsyncobjectfiles: batch disk flushes

From: Neeraj Singh <hidden>
Date: 2021-08-28 00:20:56

On Wed, Aug 25, 2021 at 10:50 PM Christoph Hellwig [off-list ref] wrote:
On Wed, Aug 25, 2021 at 05:49:45PM -0700, Neeraj Singh wrote:
quoted
One conclusion from reviewing that thread is that as of then,
sync_file_ranges isn't actually enough
to make a hard guarantee about writeout occurring. See
https://lore.kernel.org/linux-fsdevel/20190319204330.GY26298@dastard/ (local).
My hope is that the Linux FS developers have rectified that shortcoming by now.
I'm not sure what shortcoming you mean.  sync_file_ranges is a system
call that only causes data writeback.  It never performs metadata write
back and thus is not an integrity operation at all.  That is also very
clearly documented in the man page.
You're right. On re-read of the man page, sync_file_range is listed as
an "extremely dangerous"
system call.  The opportunity in the linux kernel is to offer an
alternative set of flags or separate
API that allows for an application like Git to separate a metadata
writeback request from the disk flush.

Separately, I'm hoping I can push from the Windows filesystem side to
get a barrier primitive put into
the NVME standard so that we can offer more useful behavior to
applications rather than these painful
hardware flushes.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help