On Wed, Dec 07, 2022 at 12:51:13PM -0800, Luis Chamberlain wrote: > On Wed, Nov 30, 2022 at 03:18:41PM +0000, Matthew Wilcox wrote: > > From a filesystem point of view, you need to ensure that you handle folios > > larger than PAGE_SIZE correctly. The easiest way is to spread the use > > of folios throughout the filesystem. For example, today the first thing > > we do in f2fs_read_data_folio() is convert the folio back into a page. > > That works because f2fs hasn't told the kernel that it supports large > > folios, so the VFS won't create large folios for it. > > > > It's a lot of subtle things. Here's an obvious one: > > zero_user_segment(page, 0, PAGE_SIZE); > > There's a folio equivalent that will zero an entire folio. > > > > But then there is code which assumes the number of blocks per page (maybe > > not in f2fs?) and so on. Every filesystem will have its own challenges. > > > > One way to approach this is to just enable large folios (see commit > > 6795801366da or 8549a26308f9) and see what breaks when you run xfstests > > over it. Probably quite a lot! > > Me and Pankaj are very interested in helping on this front. And so we'll > start to organize and talk every week about this to see what is missing. > First order of business however will be testing so we'll have to > establish a public baseline to ensure we don't regress. For this we intend > on using kdevops so that'll be done first. > > If folks have patches they want to test in consideration for folio / > iomap enhancements feel free to Cc us :) > > After we establish a baseline we can move forward with taking on tasks > which will help with this conversion. So ... it's been a year. How is this project coming along? There weren't a lot of commits to f2fs in 2023 that were folio related.
