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

[Alexey Lyahkov]

> 25 янв. 2025 г., в 02:24, NeilBrown <neilb at suse.de> написал(а):
> 
> On Thu, 23 Jan 2025, Alexey Lyahkov wrote:
>> 
>> 
>> 
>>    Keeping different kernels up to date with new updates is something
>>    that
>>    the linux-stable team does all the time.  We do it at SUSE to.  It
>>    isn't
>>    that hard.
>>    You identify which patches *need* to be backported (ideally when
>>    the
>>    patch is created but that isn't always easy) and you use tools to
>>    help
>>    you backport them.
>> 
>> So Lustre developers needs control all stable kernels and think which
>> patch needs back ported and send it to Distro owner 
>> And for each LTS kernels on the kernel.org.. I think it increase a work
>> dramatically.
> 
> No.  Lustre developers don't need to care about the stable kernels at
> all.  The stable team does that an explicitly say they don't want it to
> be a burden on maintainers.
Lustre maintainers don’t needs review code which affects a Lustre? It’s something new for me.
I understand a drivers changes should don’t reviewed by lustre team.
But arch/… fs/ .. mm/... kernel/ needs attention.
Lack to review will cause a very large quality degradation after short time.
As I point early - I think none of linux maintainers have a lustre cluster to test a patches before land.
They can do test own part and how to build at all. But how it affects a Lustre? A specially in performance area.
Small examples from past.
Small optimisation for page_accessed() and LRU lists fixes a problem with ext4 bitmap in memory and improve lustre performace for 10%. Due lack of read during write. (https://lwn.net/Articles/548830/)
Small change in jbd2 code - like replace list_add to list_add_tail - improve performance for 5-15% due journal handle starvation solved.
(https://www.spinics.net/lists/linux-ext4/msg84888.html)

So yes, Lustre developers can move  LTS kernels as unsupported area and if it’s broken just suggest to install an out-of-tree module with supported kernel. But did linux kernel needs a broken code in tree really?


> The lustre team *can* decide to have some involvement - adding Fixes
> tags, adding Cc: stable, even submitting backports which don't apply
> trivially.  But there is no requirement from anywhere.
> 
> The lustre community only need to focus on one upstream.
And have a broken lustre client once it don’t tested. Or lustre client will hit a performance degradation.


Neil, Tim, 

> Lustre develops who work for employers who sell support for older
> kernels might need to handle backports to those kernels and it is in
> everybody's interest not to make that unduly different e.g.  by
> separating bug fixes from features etc.
> 
Lustre primary area is ‘older’ kernels. As I point early half of customers uses a RHEL7, second 30% is RHEL8.
And just 2% uses a modern kernels.


> The lustre community may well choose to host and share those backports,
> and maybe even include them in testing.  But I suspect that would be
> driven by vendors who sell support.  It certainly wouldn't be imposed by
> the upstream community.
> 
> Exactly how we work with distros like Redhat, SUSE, Ubuntu would depend
> on what can be negotiated with them.
> Some might be willing to accept backports and release them in
> maintenance updates.  Some might not.
> In that case the way to support their kernel for your customers would be
> to start with the source for a particular maint update, add the missing
> patches, build, and distribute the result.
> You probably would only need to do this for each servie-pack, not for
> each update.
> 
> It isn't really different from what it done today, but it would be done
> in a different way.
> 
> Thanks,
> NeilBrown

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20250125/28d0482f/attachment.htm>