RFC ext4: Allocator changes for atomic write support with DIO

This patch series builds on top of John Gary's atomic direct write patch series [1] and enables this support in ext4. This is a 2 step process:

1. Enable aligned allocation in ext4 mballoc. This allows us to allocate power-of-2 aligned physical blocks, which is needed for atomic writes.

2. Hook the direct IO path in ext4 to use aligned allocation to obtain physical blocks at a given alignment, which is needed for atomic IO. If for any reason we are not able to obtain blocks at given alignment we fail the atomic write.

Currently this RFC does not impose any restrictions for atomic and non-atomic allocations to any inode, which also leaves policy decisions to user-space as much as possible. So, for example, the user space can:

* Do an atomic direct IO at any alignment and size provided it satisfies underlying device constraints. The only restriction for now is that it should be power of 2 len and atleast of FS block size.

* Do any combination of non atomic and atomic writes on the same file in any order. As long as the user space is passing the RWF_ATOMIC flag to pwritev2() it is guaranteed to do an atomic IO (or fail if not possible).

There are some TODOs on the allocator side which are remaining like...

1. Fallback to original request size when normalized request size (due to preallocation) allocation is not possible.
2. Testing some edge cases.

But since all the basic test scenarios were covered, hence we wanted to get this RFC out for discussion on atomic write support for DIO in ext4.

Further points for discussion -

1. We might need an inode flag to identify that the inode has blocks/extents atomically allocated. So that other userspace tools do not move the blocks of the inode for e.g. during resize/fsck etc.
a. Should inode be marked as atomic similar to how we have IS_DAX(inode) implementation? Any thoughts?

2. Should there be support for open flags like O_ATOMIC. So that in case if user wants to do only atomic writes to an open fd, then all writes can be considered atomic.

3. Do we need to have any feature compat flags for FS? (IMO) It doesn't look like since say if there are block allocations done which were done atomically, it should not matter to FS w.r.t compatibility.

4. Mostly aligned allocations are required when we don't have data=journal mode. So should we return -EIO with data journalling mode for DIO request?

Script to test using pwritev2() can be found here:
https://gist.github.com/OjaswinM/e67accee3cbb7832bd3f1a9543c01da9

Regards,
ojaswin

[1] https://lore.kernel.org/linux-fsdevel/[email protected]

Ojaswin Mujoo (7):
iomap: Don't fall back to buffered write if the write is atomic
ext4: Factor out size and start prediction from
ext4_mb_normalize_request()
ext4: add aligned allocation support in mballoc
ext4: allow inode preallocation for aligned alloc
block: export blkdev_atomic_write_valid() and refactor api
ext4: Add aligned allocation support for atomic direct io
ext4: Support atomic write for statx

 block/fops.c                |  18 ++-
 fs/ext4/ext4.h              |  10 +-
 fs/ext4/extents.c           |  14 ++
 fs/ext4/file.c              |  49 ++++++
 fs/ext4/inode.c             | 142 ++++++++++++++++-
 fs/ext4/mballoc.c           | 302 +++++++++++++++++++++++++-----------
 fs/iomap/direct-io.c        |   8 +-
 include/linux/blkdev.h      |   2 +
 include/trace/events/ext4.h |   2 +
 9 files changed, 442 insertions(+), 105 deletions(-)

2.39.3