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.
