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

[Alexey Lyahkov]

> On 22 Jan 2025, at 23:54, NeilBrown <neilb at suse.de> wrote:
> 
> On Mon, 20 Jan 2025, Alexey Lyahkov wrote:
>> 
>>> On 19 Jan 2025, at 11:03, NeilBrown <neilb at suse.de> wrote:
>>> 
>>> On Sun, 19 Jan 2025, Alexey Lyahkov wrote:
>>>> Neil,
>>>>> 
>>>>> 
>>>>>> 
>>>>>> It does not hep that there are what 3? 4? trees, not "dual-tree" by any
>>>>>> stretch of imagination.
>>>>>> 
>>>>>> There's DDN/whamcloud (that's really two trees), there's HPE, LLNL
>>>>>> keeps their fork still I think (thought it's mostly backports?). There
>>>>>> are likely others I am less exposed to.
>>>>> 
>>>>> "dual-tree" maybe isn't the best way of describing what was wrong with
>>>>> the previous approach.  "upstream-first" is one way of describing how it
>>>>> should be run, though that needs to be in understood correctly.
>>>>> 
>>>>> Patches should always flow upstream first, then flow downstream into
>>>>> distro.  So I write a patch in my own devel tree.  I post it or submit a
>>>>> pull request and eventually it is accepted into the maintainers
>>>>> "testing" tree (upsream from me).  There it gets more testing and moves
>>>>> to the maintainers "next" tree from which it is pulled into linux-next
>>>>> for integration testing.  Then it goes upstream to Linus (possibly
>>>>> through an intermediary).  From Linus it goes to -stable and to various
>>>>> distros etc.  Individual patches are selected for further backporting to
>>>>> all sorts of different LTS tree.
>>>>> 
>>>>> Occasionally there are short-cuts.  I might submit a patch from my tree
>>>>> to a SUSE kernel before it is accepted upstream, or maybe even before it
>>>>> is sent if it is urgent.  But these are not the norm.
>>>>> 
>>>>> But you know all this I expect.  It isn't about the total number of
>>>>> trees. It is about the flow of patches which must all flow through Linus.
>>>>> And developers must develop against current linus, or something very
>>>>> close to that.  Developing against an older kernel is simply making more
>>>>> work for yourself.
>>>> 
>>>> This will don’t work. Let explain situation in past.
>>> 
>>> No.  I'm not at all interested in explanations of why it won't work.
>>> 
>>> I'm only interested in suggestions of how to make it work, and offers of
>>> help.
>>> 
>> If you have a good way how to solve such situation, which had crazy brain in past.
>> Please share a way how to avoid lustre source code fragmentation because of freeze a code at the different stage in different distributions.
>> Ubuntu might have a modern lustre with 6.5 kernel, but Redhat had frozen a lustre version in 3 releases in past and these clients not compatible each other.
>> And not compatible with installed server.
>> So question - who will do such support ? Did you have an ideas how to solve this problem?
>> 
> 
> sorry - I didn't mean to go quite on you - I've been busy :-)
> 
> It's not entirely clear to me what the problem is.
> You talk about clients not being compatible with each other or with the
> server, but Andreas has said that there is good compatibility between
> different versions so I wonder if that is really (still) an issue.

Lustre have good compatibility, but not at all cases. It have tested with +/-1 release only.
I remember a several cases then it caused a probles with clients more than one release old.
As about Andreas, Andreas don’t work with client support for long time so don’t know about all problems in this area.

> 
> 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 <http://kernel.org/>.. I think it increase a work dramatically.

> 
> Certainly there is effort involved, but maintaining a package that works
> on a large set of kernels also involves effort.  It isn't clear to me
> that it is *more* effort, just *different* effort.
> 
> NeilBrown

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20250123/0389e618/attachment.htm>