On Fri, Jan 24, 2025 at 08:50:02PM +0000, Day, Timothy wrote: > Lustre has already received a plethora of feedback in the past. > While much of that has been addressed since - the kernel is a > moving target. Several filesystems have been merged (or removed) > since Lustre left staging. We're aiming to avoid the mistakes of > the past and hope to address as many concerns as possible before > submitting for inclusion. I'm broadly in favour of adding Lustre, however I'd really like it to not increase my workload substantially. Ideally it would use iomap instead of buffer heads (although maybe that's not feasible). What's not negotiable for me is the use of folios; Lustre must be fully converted to the folio API. No use of any of the functions in mm/folio-compat.c. If you can grep for 'struct page' in Lustre and find nothing, that's a great place to be (not all filesystems in the kernel have reached that stage yet, and there are good reasons why some filesystems still use bare pages). Support for large folios would not be a requirement. It's just a really good idea if you care about performance ;-) I hope it doesn't still use ->writepage. We're almost rid of it in filesystems. Ultimately, I think you'll want to describe the workflow you see Lustre adopting once it's upstream -- I've had too many filesystems say to me "Oh, you have to submit your patch against our git tree and then we'll apply it to the kernel later". That's not acceptable; the kernel is upstream, not your private git tree.
