On Mon, Mar 24, 2025 at 08:47:05AM +0800, Nanzhe Zhao wrote: > Knowing that the F2FS community is currently heavily invested in the > folio support effort, I wanted to also bring up some observations and > questions regarding folio support in F2FS garbage collection. > Specifically, I'm concerned about the challenge of allocating > high-order folios due to non-contiguous index ranges during the GC > process. I've initiated a discussion about this issue on the f2fs > mailing list in an email > thread.[https://lore.kernel.org/linux-f2fs-devel/CAMLCH1F8niz3qifu9pt6C3yLhonadD=feaptwkhcard8fpj...@mail.gmail.com/T/#u] > I would be grateful if you and other developers could take a look and > share your thoughts.
Sorry, I'm at LSFMM this week and don't have time to dig into this. I hope you saw my recent email about folios: https://lore.kernel.org/linux-f2fs-devel/z9rr2ubks9caf...@casper.infradead.org/ The fundamental problem is that f2fs has no per-block data structure. In ext4, that's struct buffer_head. For XFS, it's struct iomap_folio_state. For btrfs, it's struct btrfs_subpage and for bcachefs, it's struct bch_folio. Either f2fs needs to grow its own, or it needs to share iomap with XFS. Both options are a lot of work; iomap doesn't support all the functionality that f2fs needs. But btrfs is looking to move to using iomap and it has some of the same needs that f2fs has, so perhaps you can help each other. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
