Re: [LSF/MM/BPF TOPIC] Lustre filesystem upstreaming

[Matthew Wilcox <willy@infradead.org>]

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.