Re: [f2fs-dev] [RFC PATCH 0/9] f2fs: Enable buffered read/write large folios support with extended iomap

Re: [f2fs-dev] [RFC PATCH 0/9] f2fs: Enable buffered read/write large folios support with extended iomap

[赵南哲]

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" <hch@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

Re: [f2fs-dev] [RFC PATCH 0/9] f2fs: Enable buffered read/write large folios support with extended iomap

[Nanzhe Zhao]

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, "赵南哲 " <nzzhao@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" <hch@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