On 09/01/2024 16:02, Christoph Hellwig wrote:
On Tue, Jan 09, 2024 at 09:55:24AM +0000, John Garry wrote:
So a user can issue:
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
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.
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
