Re: [PATCH v2 00/16] block atomic writes

On 09/01/2024 16:02, Christoph Hellwig wrote:

On Tue, Jan 09, 2024 at 09:55:24AM +0000, John Garry wrote:

quoted

So a user can issue:

quoted

xfs_io -c "atomic-writes 64K" mnt/file
xfs_io -c "atomic-writes" mnt/file

[65536] mnt/file

Let me try to decipher that:

  - the first call sets a 64k fsx_atomicwrites_size size

It should also set FS_XFLAG_ATOMICWRITES for the file. So this step does everything to enable atomic writes for that file.

  - the secon call queries fsx_atomicwrites_size?

Right, I'm just demo'ing how it would look

quoted

The user will still have to issue statx to get the actual atomic write
limit for a file, as 'xfs_io -c "atomic-writes"' does not take into account
any HW/linux block layer atomic write limits.

So will the set side never fail?

It could fail.

Examples of when it could fail could include:

a. If user gave a bad size value. So the size should be a power-of-2 and also divisible into the AG size and compatible with any stripe alignment.

b. If the file already had flags set which are incompatible with or not supported for atomic writes.

c. the file already has data written. I guess that's obvious.

quoted

Is this the sort of userspace API which you would like to see?

What I had in mind (and that's doesn't mean it's right..) was that
the user just sets a binary flag, and the fs reports the best it
could.  But there might be reasons to do it differently.

That is what I am trying to do, but I also want to specify a size for the atomic write unit max which the user could want. I'd rather not use the atomic write unit max from the device for that, as that could be huge. However, re-reading a., above, makes me think that the kernel should have more input on this, but we still need some input on the max from the user...

Thanks,
John