Re: [PATCH v5 00/10] block atomic writes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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









[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux