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

[Oleg Drokin]

On Thu, 2025-01-23 at 07:54 +1100, NeilBrown wrote:

> 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.

Problems are multifaceted.
One is that yes we have all sorts of compatibility in the protocol, but
as you pointed out elsewhere, there's no formal protocol definition, so
it's just "whatever the code does" which does differ from version to
version at times and we do have occasional interop issues. We tend to
catch those in testing (sometimes late, and sometimes patch is client
side too), but the obvious limitation here is we only see it where we
tests and the official guarantee is a pretty narrow window, and we
cannot have an unlimited test matrix explosion to test against every
mainline kernel going back 7 or whatever years.
 
Then there are all the features people want and stuff, and having an
outdated in tree client interferes with an up to date out of tree
client building. And creating patches to random old kernels to bring
them up to date is not very exciting, and of course there's the extra
fun of then getting distro people to even accept those patches.

> 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.

This probably makes backporting features not very convenient (and
distro people would push back with "oh no, stability/bug fixes only
please!"
(there are benefits too of course, once you manage to push something
through to the distro people, people are often much better at following
the distro kernel updates)

> 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.

yes.
Also "works" is such a nebulous word in this context as I just got
rhel8.10 and rhel9.5 with all sorts of extra debug not normally enabled
by distro people into my test rigs and fireworks ensued (different ones
for those different versions).