On 30/11/2023 21:10, Dave Chinner wrote:
On Thu, Nov 30, 2023 at 07:23:09PM +0530, Ojaswin Mujoo wrote:
Currently, iomap only supports atomic writes for direct IOs and there is
no guarantees that a buffered IO will be atomic. Hence, if the user has
explicitly requested the direct write to be atomic and there's a
failure, return -EIO instead of falling back to buffered IO.
Signed-off-by: Ojaswin Mujoo<ojaswin@xxxxxxxxxxxxx>
---
fs/iomap/direct-io.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index 6ef25e26f1a1..3e7cd9bc8f4d 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -662,7 +662,13 @@ __iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
if (ret != -EAGAIN) {
trace_iomap_dio_invalidate_fail(inode, iomi.pos,
iomi.len);
- ret = -ENOTBLK;
+ /*
+ * if this write was supposed to be atomic,
+ * return the err rather than trying to fall
+ * back to buffered IO.
+ */
+ if (!atomic_write)
+ ret = -ENOTBLK;
This belongs in the caller when it receives an -ENOTBLK from
iomap_dio_rw(). The iomap code is saying "this IO cannot be done
with direct IO" by returning this value, and then the caller can
make the determination of whether to run a buffered IO or not.
For example, a filesystem might still be able to perform an atomic
IO via a COW-based buffered IO slow path. Sure, ext4 can't do this,
but the above patch would prevent filesystems that could from being
able to implement such a fallback....
Sure, and I think that we need a better story for supporting buffered IO
for atomic writes.
Currently we have:
- man pages tell us RWF_ATOMIC is only supported for direct IO
- statx gives atomic write unit min/max, not explicitly telling us it's
for direct IO
- RWF_ATOMIC is ignored for !O_DIRECT
So I am thinking of expanding statx support to enable querying of atomic
write capabilities for buffered IO and direct IO separately.
Thanks,
John
