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
