[lustre-devel] [LSF/MM/BPF TOPIC] [DRAFT] Lustre client upstreaming

[Alexey Lyahkov]

Timothy,


> 22 янв. 2025 г., в 09:35, Day, Timothy <timday at amazon.com> написал(а):
> 
> I've created a second draft of the topic for LSF/MM. I tried
> to include everyone's feedback. It's at the end of the email.
> 
> Before that, I wanted to elaborate on Neil's idea about updating
> our development model to an upstream-focused model. For upstreaming
> to work, the normal development flow has to generate patches to mainline
> Linux - while still supporting the distro kernels that most people use
> to run Lustre. I think we can get this point in stages. I've provided
> a high-level overview in the next section. This won't be without
> challenges - but the majority of the transition could happen without
> interrupting feature work or normal development.

Can you explain how Lustre platform fragmentation will avoid ?

I posted example early,
Distro have locked a Lustre version in release time. But Lustre server have a limited compatibility - in most cases +/- 1…2 releases guaratee to be connected. So stale and aged client will live in the distribution kernel. And it will don’t work for modern servers.
it’s very easy  Once distribution live time ~8y. So clients will be needs to drop in kernel lustre client support and install a lustre client from an external sources. Which have no differences with current state. 
Next step is sort of distributions which have a different lustre versions which not compatible each to other.
Both these increase a support cost - once large number versions needs supported, so development will drops and all time will spent to support.

It this is not enough - lets one more. Kernel API isn’t stable enough - so large number resources will be needs spent to solve each kernel change in lustre. Currently, it’s in the background and don’t interrupt primary work for supporting and development a new Lustre features.

So that is problems for Lustre world - what is benefits?


Alex