Hi F2FS developers, I'm testing multi-threaded direct I/O in LFS mode on Linux kernel 6.8.0-57.59, and noticed what seems to be an inefficiency in block allocation behavior inside `fs/f2fs/data.c` (specifically `f2fs_map_blocks()`):
1. In LFS mode with direct I/O, `f2fs_map_blocks()` always calls `__allocate_data_block()` to reserve a new block and updates the node/NAT entry, regardless of extent continuity. 2. If the new block is not physically contiguous with the current extent, it submits the current bio and defers the write of the newly reserved block (which is now recorded in the node) to the next mapping. 3. On the next `f2fs_map_blocks()` call, it finds that the logical block is already mapped in the node/NAT entry and skips over it—despite the block never having been written—resulting in allocation of yet another block. Over time, this leaves behind holes in the current segment, especially under heavy multi-threaded DIO. Since I'm still new to F2FS internals, I may be missing something — I'd like to understand the design rationale behind this behavior in LFS mode, if possible. **My questions are:** - Is there a specific reason F2FS does not distinguish between reserved-but-unwritten and already-written blocks in this case? - Would it be possible (or beneficial) to: 1. Delay block allocation until the extent can actually be extended? 2. Track "reserved-but-unwritten" blocks distinctly to avoid reallocation? Thanks in advance for any clarification or insight. Best regards, Gyjin Kim _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
