Dear Matthew, Hope you are doing well. I've recently made some progress in enabling iomap support for buffered read and buffered write on regular files in f2fs. However, I'm encountering significant challenges when it comes to supporting iomap for page writeback.
Currently, the f2fs_write_cache_pages function is indeed aware of larger order folio Well, its implementation involves setting a threshold, collecting a fixed number of pages from a folio on the stack, and then submitting IOs page by page using f2fs_write_single_page one by one. In other words, this results in folio -> page -> bio IO path. My understanding of iomap's writepages implementation is to treat a folio itself as a complete IO unit, rather than breaking it down into pages. Within the iomap_writepage_map_blocks framework, we consider both the mapping length returned by the filesystem's wpc->ops->map_blocks function and the dirty length within the folio to determine the final map_len. Then, we directly add this length and the folio to the bio, thus forming a direct folio-to-bio IO path. However, for f2fs, the tight coupling between its unique IO information structure, f2fs_io_info, and individual pages presents several challenges. For instance, f2fs_io_info stores both the old and new data block addresses from the dnode_of_data of a data page. Since f2fs employs both inplace and outplace update mechanisms, the old data block address becomes unreliable for write IO during outplace updates (a problem not encountered in read IO). This poses difficulties when writing back an entire folio. If we were to use iomap_writepages, wpc->ops->map_blocks might even need to differentiate between blocks within a folio that require inplace updates and those requiring outplace updates, and then split the mapping length accordingly. I feel this would lead to complex and confusing code. Furthermore, f2fs's current bio merging strategy considers not only the contiguity of adjacent filesystem blocks but also whether the io_type of two f2fs_io_info structures is the same. This information would be lost within the iomap writepage framework. Intuitively, I do believe iomap's approach of directly submitting a folio as a single unit to bio is very reasonable. After all, a folio contains sufficient information to do so, as it holds the logical indices of all pages. However, due to the aforementioned issues, f2fs currently has to decompose folios into pages for write IO. Moreover, if functions in GC and page cache that perform IO also aim to support folios, they might also have to resort to looping and decomposing folios into pages. What are your thoughts on this issue? Do you think decomposing folios into pages using loops would violate the design philosophy of folios? Or do you believe this approach is sufficient for f2fs IO? If we want to move away from this decomposition approach, do you have any suggestions? Looking forward to your reply. Best regards. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
