There's another important reason to utilize an f2fs_iomap_folio_state. Because f2fs doesn't possess a per block state tracking data structure like buffer heads or subpages, it can't track per block dirty state or read/write bytes pending itself. Growing such a structure for f2fs and applying it to all code paths could be a tremendous and destructive task.
So I think it's convenient to possess an f2fs own per folio private data structure that can both be compatible with iomap and f2fs's needs, especially helpful for other f2fs's i/o paths that need to support large folios altogether with buffered io but can't go into iomap path (i.e., garbage collection). It can also be extended with fields to meet the needs of other types of f2fs files (e.g., compressed files) if they need to support large folios too. At 2025-08-14 08:39:31, "赵南哲 " <nzz...@126.com> wrote: >Hi Mr.Christoph, > >Thanks for the quick feedback! > >> That's pretty ugly. What additional flags do you need? > >F2FS can utilize the folio's private field in a non-pointer mode to store its >extra flags, which indicate the folio's additional status. >Please take a look at the f2fs.h file from PAGE_PRIVATE_GET_FUNC to the end of >clear_page_private_all(). > >These flags persist throughout the entire lifetime of a folio, which conflicts >with the iomap_folio_state pointer. >Currently, the private fields of iomap's existing data structures,namely >struct iomap's private, struct iomap_iter's private, >and struct iomap_ioend's io_private,are either allocated locally on the stack >or have a lifecycle on the heap that only exists >for the duration of the I/O routine. This cannot meet F2FS's requirements. > >> We should try to figure out if there is a sensible way to support the needs >> with a single codebase and data structure. > >As far as I know, only F2FS has this requirement, while other file systems do >not. >Therefore, my initial thought was to avoid directly modifying the generic >logic in fs/iomap. Instead, I propose designing >a wrapper structure for iomap_folio_state specifically for F2FS to satisfy >both iomap's and F2FS's own needs. > >Another issue is the handling of order-0 folios. Since the iomap framework >does not allocate an iomap_folio_state for these folios, >F2FS will always stores its private flags in the folio->private field. Then >iomap framework would mistakenly interpret these flags as a pointer. > >If we are to solve this issue in generic iomap layer, a minimal changes method >to iomap framework I suppose is to let iomap logic can >both distinguish pointer and non pointer mode of folio->private. We should >also add a private field to iomap_folio_state , or extend he state >flexible array to store the extra infomation. If iomap detects a order>0 >folio's folio->private is used in non pointer mode, then it store the flags in >a newly >allocted iomap_folio_state first , clear the private field and then store's >its address in it. > >P.S. I just noticed you didn't reply via my resend patch. I misspelled f2fs's >subsytem mail address in the original patch and I sincerely apologize for that. >I already re-sent the series as > "[f2fs-dev] [RESEND RFC PATCH 0/9] f2fs: Enable buffered read/write large > folios support with extended iomap" >Could we continue the discussion on that thread so the right list gets the >full context? Thanks! > >Best regards, >Nanzhe Zhao > >At 2025-08-13 23:22:37, "Christoph Hellwig" <h...@infradead.org> wrote: >>On Wed, Aug 13, 2025 at 05:21:22PM +0800, Nanzhe Zhao wrote: >>> * **Why extends iomap** >>> * F2FS stores its flags in the folio's private field, >>> which conflicts with iomap_folio_state. >>> * To resolve this, we designed f2fs_iomap_folio_state, >>> compatible with iomap_folio_state's layout while extending >>> its flexible state array for F2FS private flags. >>> * We store a magic number in read_bytes_pending to distinguish >>> whether a folio uses the original or F2FS's iomap_folio_state. >>> It's chosen because it remains 0 after readahead completes. >> >>That's pretty ugly. What additionals flags do you need? We should >>try to figure out if there is a sensible way to support the needs >>with a single codebase and data structure if that the requirements >>are sensible. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
