Dear Mr Matthew Hi! It's been a long time since we last discuss about f2fs supporting large folios. I hope you're doing well! Over the past three months, I've been working on large folios support in my own fork of the f2fs tree. I've made some significant progress and have a working implementation for: - f2fs's own per folio struct f2fs_iomap_folio_state - iomap-based buffered read and write. - Large folios support for compressed files, including both buffered I/O and page writeback. My work is based on a several commits just after your "f2fs folio conversions for 6.16" series on f2fs's dev-test branch(Not the mainline) It can handle run on some simple read/write operations for both normal and compressed files, but it is still largely untested. You can find my WIP branch here: I saw your recent series of patches for large folios support and was excited to see the progress. I'm writing to you today to share an update from my side and ask for some guidance. Regarding our previous discussion about storing extra f2fs flags in folio->private, I implemented a solution using a new f2fs_iomap_folio_state struct and related APIs, which I placed in new files (f2fs_ifs.c/.h). My design not only supports large folios but also maintains compatibility with order-0 data and metadata folios which storing the f2fs private flags directly in folio->private.iomap_folio_state won't allocate for them. The memory layout of my struct is also compatible with iomap's helpers.Now this piece of code conflicts with your latest patches that introduce folio_set_f2fs_data. I assume the standard kernel development workflow would be for me to rebase my local branch onto your latest commit and then refactor my code to align with your new API. Is that correct? I am more than happy to do so and adapt my implementation. On a related note, I recently learned that storage engineers from vivo also implemented iomap buffered write and page writeback conversions for f2fs last year. (The latter shocks me, and I'll explain the reason in a future conversation). Their work seemed doesn't include support for compressed file large folios. It seems necessary for me to coordinate with them. Looking ahead, I understand that a feature of this size should be submitted as a series of small, logical patches to make the review process easier. I would be grateful for any thoughts you might have on this approach as well.
Any feedback on my work or advice on how to proceed would be greatly appreciated. Thanks for your time. Best regards. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
