This is an RFC patch before LSFMM to preview the change of how multi-fsblock atomic write support with bigalloc look like. There is a scope of improvement in the implementation, however this shows the general idea of the design. More details are provided in the actual patch. There are still todos and more testing is needed. But with iomap limitation of single fsblock atomic write now lifted, the patch has definitely started to look better. This is based out of vfs.all tree [1] for 6.15, which now has the necessary iomap changes required for the bigalloc support in ext4. TODOs: 1. Add better testcases to test atomic write support with bigalloc. 2. Discuss the approach of keeping the jbd2 txn open while zeroing the short underlying unwritten extents or short holes to create a single mapped type extent mapping. This anyway should be a non-perfomance critical path. 3. We use ext4_map_blocks() in loop instead of modifying the block allocator. Again since it's non-performance sensitive path, so hopefully it should ok? Because otherwise one can argue why take and release EXT4_I(inode)->i_data_sem multiple times. We won't take & release any group lock for this, since we know that with bigalloc the cluster is anyway available to us. 4. Once when we start supporting file/inode marked with atomic writes attribute, maybe we can add some optimizations like zero out the entire underlying cluster when someone forcefully wants to fzero or fpunch an underlying disk block, to keep the mapped extent intact. 5. Stress test of this is still pending through fsx and xfstests. Reviews are appreciated. [1]: https://web.git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs.all&id=4f76518956c037517a4e4b120186075d3afb8266 Ritesh Harjani (IBM) (1): ext4: Add atomic write support for bigalloc fs/ext4/inode.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++-- fs/ext4/super.c | 8 +++-- 2 files changed, 93 insertions(+), 5 deletions(-) -- 2.48.1
