Details
-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
3
-
9223372036854775807
Description
This brings explicit support in for the following versions of Ubuntu, which required refreshes of various ldiskfs kernel patches along the way:
- 20.04 at 5.4.0-1091
- 20.04 at 5.4.0-1095
- 20.04 at 5.15.0-1034
- 20.04 at 5.15.0-1046
- 20.04 at 5.15.0-1056
- 20.04 at 5.15.0-1058
Patch version between the 5.4 and 5.15 patch versions shown function as well, as does 5.15.0 up to the most recent patch available today. Most testing was performed on 20.04.6 LTS, though some of the 5.4 testing was on 18.04 as well as 20.04 versions.
Patch to be sent shortly.
Attachments
Activity
Given the timing I suggest we discuss this properly in realtime at LUG.
Note I didn't see the intermediate comments (my previous comment was open and uncommitted in my browser), but I think my comments still stand. It makes the most sense to add/update the series for the latest kernels of each series, but IMHO it doesn't make sense to add series for older kernels. It is unlikely that sites starting with a brand new Lustre 2.16.0 install will be installing one of the older Ubuntu 20.04 5.4 kernels with it, but rather the latest Ubuntu kernel.
It would be good to understand the overarching approach here. Looking at recent additions to ldiskfs/, I see:
Jan 18th 2024: 20.04.5 5.15 support (not EOL until April 2025)
Jan 13th 2024: 20.04.5 5.11 support (not EOL until April 2025)
Jan 4th 2024: RHEL 9.3 support (not EOL until May 2027)
Nov 20th 2023: RHEL 8.9 support (EOL next month)
Oct 18th 2023: RHEL 9.2 support (not EOL until May 2027)
Aug 15th 2023: SUSE 15 SP3 support (EOL well before this commit)
This is driven by what is in use at customer sites, and what developers are willing to maintain. Shaun Tancheff has been doing a lot of the work to add newer ldiskfs series, but we have also recently been pruning old series (el7.8- and el8.3-) from the tree before the 2.16 release, since they are untested and unmaintained.
If the desired approach is to merge this to an earlier release (e.g., 2.15.next, or 2.16), that's fine by me too. I thought the model was to merge to master and then backport as-needed. Let me know which release would be most useful (we are on 2.15.4 now, so at least this series would be good, and we're considering moving to 2.16.* shortly after its release depending on the contents, so I'd ideally like that one as well).
Typically the addition of new kernel/distro support happens incrementally during the development cycle, but is largely driven by the needs of users/maintainers. IMHO, updating the 5.4.0 kernels in b2_15 would be OK, but adding e.g. el9.3 or Ubuntu 5.15 server kernel support there would be very dependent on how intrusive such patches are to the existing code. It is of course still possible to keep a local fork with b2_15 + older ldiskfs patch series as you've been doing so far.
One last thing – Ubuntu 22.04 is on Linux 6.5, and Ubuntu 24.04 is on Linux 6.8. I was under the impression that these two were not yet supported in ldiskfs patches. If that is not the case, please let me know!
I don't follow this closely, but AFAIK Ubuntu 22.04 was using kernel 5.15? Maybe that is a recent "advanced" kernel in preparation for 24.04, but I think most systems were running 5.15 over the past couple of years?
As for Ubuntu 24.04 and Linux 6.8, somebody has to do the work to port the kernel patch series to these new kernels, and I don't think anyone has had a desire/demand to take on that effort yet, since the servers are usually a bit isolated and maintained by the vendors, while users have a free-for-all with the clients (much moreso in cloud than on-prem). We are running only RHEL server kernels locally, so that is where our development efforts are focused. If you are running Ubuntu on the servers, then it makes sense to start with the latest ldiskfs kernel series and work forward from that.
All good! I'm totally ok with reducing this to singular support for 5.15 1058. Note however that I'd be uncomfortable with eliminating the <1000 patch version stream, as the normal linux-hwe kernels begin their counting at 0, while the canonical vendor specific patch versions begin at 1000. For example, the latest generally available linux-hwe is:
https://packages.ubuntu.com/focal-updates/linux-image-unsigned-5.15.0-102-generic
While the latest azure-specific signed image is:
https://packages.ubuntu.com/focal-updates/kernel/linux-image-5.15.0-1060-azure
Accordingly, my preference would be to keep some checks I've put into place that check patch version and would keep unsigned "normal" Ubuntu users on the latest in that stream (i.e., I don't want to break James use of normal Ubuntu), while those above 1000 would default to our latest. If at some point there is more than one vendor interested in ubuntu it would make sense to further diversify based on the trailing vendor name.
My bad, I was mixing up versions. It looks like 22.04 is mostly used on the clients, but ldiskfs patch series are still using 20.04. Even so, I think the focus should be on updating only the most recent kernel series (ldiskfs-5.15.0-83-ubuntu20.series) since it looks like this can also be used for both Ubuntu 20.04 and Ubuntu 22.04
It would be good to understand the overarching approach here. Looking at recent additions to ldiskfs/, I see:
- Jan 18th 2024: 20.04.5 5.15 support (not EOL until April 2025)
- Jan 13th 2024: 20.04.5 5.11 support (not EOL until April 2025)
- Jan 4th 2024: RHEL 9.3 support (not EOL until May 2027)
- Nov 20th 2023: RHEL 8.9 support (EOL next month)
- Oct 18th 2023: RHEL 9.2 support (not EOL until May 2027)
- Aug 15th 2023: SUSE 15 SP3 support (EOL well before this commit)
I quickly scanned the history of ldiskfs – totally possible I've missed some support additions here and I just stopped here as there was precedence for adding support for something that wasn't EOL for at a year (in fact 15 SP3 came in already EOL). If there has been a recent change of approach on what is allowed to be merged to master for ldiskfs patches, that's fine – just let me know what the rules and regulations are here.
If the desired approach is to merge this to an earlier release (e.g., 2.15.next, or 2.16), that's fine by me too. I thought the model was to merge to master and then backport as-needed. Let me know which release would be most useful (we are on 2.15.4 now, so at least this series would be good, and we're considering moving to 2.16.* shortly after its release depending on the contents, so I'd ideally like that one as well).
If the math here is based on customers, let's just say the Lustre community has a lot of customers running Lustre server code on Ubuntu 20.04 and 5.15 presently. We do not anticipate moving to 22.04 until late this year at best for a variety of reasons.
One last thing – Ubuntu 22.04 is on Linux 6.5, and Ubuntu 24.04 is on Linux 6.8. I was under the impression that these two were not yet supported in ldiskfs patches. If that is not the case, please let me know!
> I think there is relatively little value to updating all of the Ubuntu 20.04 kernels at this point, since 22.04 is the one mostly in use today, and 24.04 is just being released.
I would go a step further and say that it is not worthwhile to merge an Ubuntu 20.04 patch series to master at this late stage - even 22.04 would be questionable. If anything we should be removing some of the older patch series already there in favor of the series to support more current releases of the Linux distributions!
Thanks Andreas – we are on 20.04 for the near-term for a variety of reasons, so it's important for us to keep that up to date. I have a patch already prepped for this and am just going through the motions to learn the gerrit upstreaming process. Perhaps in the review for that you can suggest good ways for me to cull some of the list?
Ellis, we generally do not keep separate ldiskfs kernel series for every intermediate kernel version available. This is a maintenance nightmare in the Git repo, and unlikely to help most users. Typically, we only keep the ldiskfs series uptodate for the most recent kernel version of a specific distro (mostly el8/el9, and Ubuntu 22.04 is increasingly popular). Users that are upgrading Lustre will almost always be upgrading the kernel at the same time, so it doesn't make sense to do the full cross-product of versions. I think there is relatively little value to updating all of the Ubuntu 20.04 kernels at this point, since 22.04 is the one mostly in use today, and 24.04 is just being released.
"Ellis Wilson <elliswilson@microsoft.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/54759
Subject: LU-17737 ldiskfs: Support for Ubuntu 5.4.0-109*/5.15.0-1034+
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: f2a149f1ff47e19f45f99940eba3adae0f6c5ef8