On 05/03/2024 23:10, Matthew Wilcox wrote:
On Mon, Feb 26, 2024 at 05:36:02PM +0000, John Garry wrote:
This series introduces a proposal to implementing atomic writes in the
kernel for torn-write protection.
The API as documented will be unnecessarily complicated to implement
for buffered writes, I believe. What I would prefer is a chattr (or, I
guess, setxattr these days) that sets the tearing boundary for the file.
The page cache can absorb writes of arbitrary size and alignment, but
will be able to guarantee that (if the storage supports it), the only
write tearing will happen on the specified boundary.
In the "block atomic writes for XFS" series which I sent on Monday, we
do use setxattr to set the extent alignment for an inode. It is not a
tearing boundary, but just rather effectively sets the max atomic write
size for the inode. This extent size must be a power-of-2. From this we
can support atomic write sizes of [FS block size, extent size] for
direct IO.
For bdev file operations atomic write support in this series for direct
IO, atomic write size is limited by the HW support only.
We _can_ support arbitrary power-of-two write sizes to the page cache,
but if the requirement is no tearing inside a single write, then we
will have to do a lot of work to make that true. It isn't clear to me
that anybody is asking for this; the databases I'm aware of are willing
to submit 128kB writes and accept that there may be tearing at 16kB
boundaries (or whatever).
In this case, I would expect the DB to submit 8x separate 16KB writes.
However if we advertise a range of supported sizes, userspace is
entitled to use that, i.e. they could submit a single 128kB write, if
supported.
As for supporting buffered atomic writes, the very simplest solution for
regular FS files is to fix the atomic write min and max size at the
extent size, above. Indeed, that might solve most or even all usecases.
This is effectively same as your idea to set a boundary size, except
that userspace must submit individual 16KB writes for the above example.
As for bdev file operations, extent sizes is not a thing, so that is
still a problem.
Having said all this, from discussion "[LSF/MM/BPF TOPIC] untorn
buffered writes", I was hearing that can use a high-order for RWF_ATOMIC
data and it would be just a matter of implementing support in the page
cache, like dealing with already-present overlapping smaller folios - is
implementing this now the concern?
Thanks,
John
