Re: [PATCH v7 11/14] xfs: add xfs_file_dio_write_atomic()

[John Garry <john.g.garry@oracle.com>]

On 21/04/2025 22:18, Luis Chamberlain wrote:
>> /*
>> +	 * The retry mechanism is based on the ->iomap_begin method returning
>> +	 * -ENOPROTOOPT, which would be when the REQ_ATOMIC-based write is not
>> +	 * possible. The REQ_ATOMIC-based method typically not be possible if
>> +	 * the write spans multiple extents or the disk blocks are misaligned.
>> +	 */
>> +	if (ret == -ENOPROTOOPT && dops == &xfs_direct_write_iomap_ops) {
> Based on feedback from LSFMM, due to the performance variaibility this
> can introduce, it sounded like some folks would like to opt-in to not
> have a software fallback and just require an error out.
 > > Could an option be added to not allow the software fallback?

I still don't see the use in this.

So consider userspace wants to write something atomically and we fail as 
a HW-based atomic write is not possible. What is userspace going to do next?

I heard something like "if HW-based atomics are not possible, then 
something has not been configured properly for the FS" - that something 
would be extent granularity and alignment, but we don't have a method to 
ensure this. That is the whole point of having a FS fallback.

> 
> If so, then I think the next patch would also need updating.
> 
> Or are you suggesting that without the software fallback atomic writes
> greater than fs block size are not possible?

Yes, as XFS has no method to guarantee extent granularity and alignment.