From: Oleg Drokin <green@whamcloud.com>
To: "neilb@suse.de" <neilb@suse.de>,
"alexey.lyashkov@gmail.com" <alexey.lyashkov@gmail.com>
Cc: "lustre-devel@lists.lustre.org" <lustre-devel@lists.lustre.org>
Subject: Re: [lustre-devel] [LSF/MM/BPF TOPIC] [DRAFT] Lustre client upstreaming
Date: Wed, 22 Jan 2025 21:44:57 +0000 [thread overview]
Message-ID: <9a6b4df4e23db0255e0854c1c16bef89d9c35b02.camel@whamcloud.com> (raw)
In-Reply-To: <173757925141.22054.738723965751021240@noble.neil.brown.name>
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).
_______________________________________________
lustre-devel mailing list
lustre-devel@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
next prev parent reply other threads:[~2025-01-22 21:45 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 21:25 [lustre-devel] [LSF/MM/BPF TOPIC] [DRAFT] Lustre client upstreaming Day, Timothy
[not found] ` <C9513675-3287-4784-90B7-AD133328C42A@ddn.com>
2025-01-17 22:46 ` Day, Timothy
2025-01-18 0:45 ` NeilBrown
2025-01-18 3:16 ` Oleg Drokin
2025-01-18 21:46 ` Day, Timothy
2025-01-19 20:46 ` Oleg Drokin
2025-01-20 4:38 ` Day, Timothy
2025-01-20 5:37 ` Oleg Drokin
2025-01-23 9:00 ` Alexey Lyahkov
2025-01-18 22:48 ` NeilBrown
2025-01-19 6:37 ` Alexey Lyahkov
2025-01-19 8:03 ` NeilBrown
2025-01-19 16:12 ` Alexey Lyahkov
2025-01-22 20:54 ` NeilBrown
2025-01-22 21:44 ` Oleg Drokin [this message]
2025-01-23 4:51 ` Alexey Lyahkov
2025-01-24 23:24 ` NeilBrown
2025-01-25 9:09 ` Alexey Lyahkov
2025-01-25 23:25 ` NeilBrown
2025-01-19 21:20 ` Oleg Drokin
2025-01-24 23:12 ` NeilBrown
2025-01-25 6:40 ` Oleg Drokin
2025-02-01 22:19 ` NeilBrown
2025-02-01 23:25 ` Oleg Drokin
2025-02-03 17:24 ` Day, Timothy
2025-02-03 19:42 ` Oleg Drokin
2025-02-03 20:10 ` Day, Timothy
2025-02-03 20:24 ` Oleg Drokin
2025-02-03 20:29 ` Oleg Drokin
2025-02-04 17:33 ` Andreas Dilger
2025-02-04 18:38 ` Oleg Drokin
2025-02-04 23:43 ` Patrick Farrell
2025-02-05 12:05 ` Andreas Dilger
2025-02-06 18:36 ` Day, Timothy
2025-02-06 19:08 ` Oleg Drokin
2025-02-06 18:24 ` Day, Timothy
2025-02-06 18:47 ` Oleg Drokin
2025-01-18 17:51 ` Day, Timothy
2025-01-18 22:21 ` NeilBrown
2025-01-20 3:57 ` Day, Timothy
2025-01-21 17:02 ` Patrick Farrell
2025-01-22 6:57 ` Andreas Dilger
2025-01-22 17:33 ` Day, Timothy
2025-01-22 20:48 ` NeilBrown
[not found] ` <E4481869-E21A-4941-9A97-8C59B7104528@ddn.com>
2025-01-18 22:25 ` NeilBrown
2025-01-20 4:54 ` Day, Timothy
2025-01-22 6:35 ` Day, Timothy
2025-01-22 7:09 ` Andreas Dilger
2025-01-22 11:12 ` Alexey Lyahkov
2025-01-22 17:17 ` Day, Timothy
2025-01-22 17:48 ` Alexey Lyahkov
2025-01-24 17:06 ` Day, Timothy
2025-01-24 19:23 ` Alexey Lyahkov
2025-01-29 19:00 ` Day, Timothy
2025-01-29 19:32 ` Alexey Lyahkov
2025-02-01 22:58 ` NeilBrown
2025-02-01 23:23 ` NeilBrown
2025-02-02 7:33 ` Alexey Lyahkov
2025-02-03 17:33 ` Day, Timothy
2025-02-03 17:43 ` Alexey Lyahkov
2025-01-24 15:53 ` Day, Timothy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a6b4df4e23db0255e0854c1c16bef89d9c35b02.camel@whamcloud.com \
--to=green@whamcloud.com \
--cc=alexey.lyashkov@gmail.com \
--cc=lustre-devel@lists.lustre.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).