[lustre-devel] Lustre upstreaming status.
degremoa at amazon.com
Fri Dec 27 08:04:25 PST 2019
Thanks for that.
My understanding is that the only sustainable plan at long term is for linux lustre client to be the same code that OpenSFS master branch
- without backward compat ifdef and similar
- without server specific code.
We need to avoid managing a kind of fork because it will too difficult to maintain both branches. IPV6 support in LNET should be at least half accepted in OpenSFS branch before going too far on that front.
Le 19/12/2019 06:32, « lustre-devel au nom de NeilBrown » <lustre-devel-bounces at lists.lustre.org au nom de neilb at suse.de> a écrit :
At the LUG in Houston, I said that I hoped to submit something upstream
by the end of 2019. Clearly that isn't going to happen now.
The main reason that caused me to not even try is IPv6 support.
It became apparent to me that LNet would not be accepted until it has
working IPv6 support, and that doesn't exist yet.
I hope to put some development time into IPv6, and to have something
that works and is worth reviewing by the end of January 2020.
The other issue is that development has progressed slowly because
there is no spare review bandwidth. James has contributed a lot, and
others have helped, but reviewing patches for two code streams (OpenSFS
and Linux-upstream) turns out to be too much to ask for.
So I've decided to take a different approach. From now on I'm not
going to wait for reviews for patches going into my linux-lustre tree.
Part of my justification for this is that historically, review hasn't
really provided much promise of correctness. Patches go missing.
Random lines from patches go missing. Errors creep in in other ways.
Instead, I am developing a tool which will compare OpenSFS lustre
and Linux-lustre and report relevant differences. I have a prototype
working, and it is helping me to find missing patches and parts of
patches in both trees.
I will continue to submit patches to gerrit to bring OpenSFS closer to
my linux tree when that is needed, and will apply patches from OpenSFS
to my tree without extra review when that it needed.
When the time comes to submit upstream, I plan to present the tool so
that other developers can confirm that what I am submitting is
functionally equivalent to OpenSFS, and so that we can ensure the
Consequently my "lustre" branch will jump forward to v5.4 soon,
probably tomorrow, and will remain close to mainline.
I will also be growing my list of outstanding OpenSFS patches
(currently about 100, many of which haven't been submitted to gerrit
yet) and will hope to get those reviewed. Any changes that result from
the review will be detected by my comparison script when the patch
lands, and I'll update linux-lustre to match.
My new goal for upstream submission is the end of Q1-2020. This is
probably a bit optimistic, but gives me a suitable focus.
More information about the lustre-devel