On Tue, Apr 01, 2025 at 10:17:42PM +0800, Nanzhe Zhao wrote: > Based on my understanding after studying the code related to F2FS's > use of the private field of the page structure, it appears that F2FS > employs this field in a specific way. If the private field is not > interpreted as a pointer, it seems it could be used to store > additional flag bits. A key observation is that these functions seem > to apply to tail pages as well. Therefore, as you mentioned, if we are > using folios to manage multiple pages, it seems reasonable to consider > adding a similar field within the iomap_folio_state structure. This > would be analogous to how it currently tracks the uptodate and dirty > states for each subpage, allowing us to track the state of these > private fields for each subpage as well. Because it looks just like > F2FS is utilizing the private field as a way to extend the various > state flags of a page in memory. Perhaps it would be more appropriate > to directly name this new structure f2fs_folio_state? This is because > I'm currently unsure whether it will interact with existing iomap APIs > or if we will need to develop F2FS-specific APIs for it.
At this point, f2fs has no concept of head/tail pages. Because it doesn't tell the VFS that it can handle large folios, it will only see order-0 pages. The page->private member will go away, so filesystems cannot depend on being able to access it. They only get folio->private, and it's recommended (but not required) that they use that to point to their own private per-folio struct. I do think the best approach is to extend iomap and then have f2fs use iomap, but I appreciate that is several large jobs. It's worth it because it completely insulates f2fs from having to deal with pages/folios (except for metadata) > > You're right that f2fs needs per-block dirty tracking if it is to > > support large folios. > > I feel that we need to consider more than just this aspect. In fact, > it might be because we are still in the early stages of F2FS folio > support,so it leaves me the impression that the current F2FS folio > implementation is essentially just replacing struct page at the > interface level. It effectively acts just like a single page, or in > other words, a folio of order 0. Right, that's the current approach. We're taking it because the page APIs are being removed. The f2fs developers have chosen to work on other projects instead of supporting large folios (which is their right), but they can't hold up the conversion of the entire filesystem stack from pages to folios, so they're getting the minimal conversion and can work on large folios when they have time. > As you can see in f2fs_mpage_readpages, after each folio is processed > in the loop, the nr_pages counter is only decremented by 1. Therefore, > it's clear that when the allocated folios in the page cache are all > iterated through, nr_pages still has remaining value, and the loop > continues. This naturally leads to a segmentation fault at index = > folio_index(folio); due to dereferencing a null pointer. Furthermore, > only the first page of each folio is submitted for I/O; the remaining > pages are not filled with data from disk. Yes, there are lots of places in f2fs that assume a folio only has a single page. > I am planning to prepare patches to address these issues and submit > them soon. I noticed you recently submitted a big bunch of patches on > folio. I would like to debug and test based on your patch.Therefore, I > was wondering if it would be possible for you to share your modified > F2FS code directly, or perhaps provide a link to your Git repository? > Manually copying and applying so many patches from the mailing list > would be quite cumbersome. Ah, you need a tool called b4. Your distro may have it packaged, or you can get it from: https://git.kernel.org/pub/scm/utils/b4/b4.git _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
