[LU-253] 1.8 and 2.1 Patched kernels are indistinguishable to a user.

• Status: Resolved
• Project: Lustre
• Type: Bug
• Priority: Minor
• Reporter: Richard Henwood (Inactive)
• Assignee: WC Triage
• Resolution: Won't Fix
• Severity: 3

Description

After installing a patched kernel from build.whamcloud.com, it is not possible to reliably distinguish if this kernel is patched for 1.8 Lustre or 2.1 Lustre.

Comments

[Andreas Dilger]

I wouldn't object to us shipping a single kernel for both 1.8 and 2.1 that had all of the needed patches. That would allow customers to upgrade their 1.8 installation to a 1.8.6.wc1 (or whatever) with the unified-patch kernel, and then only have to upgrade the Lustre RPMs in order to move to 2.1 (or back again, if needed). This is definitely a "value add" that we can do for users that get their 1.8.6 from WC.

It looks in fact that the diff between the 1.8.6 RHEL5 kernel and master RHEL5 are fairly minor:

-i_filter_data.patch

This one could be ignored, we don't use i_filter_data even on 1.8, I believe.

-md-mmp-unplug-dev.patch
+raid5-mmp-unplug-dev.patch

Just a patch rename, not sure why it was done.

+export-symbols-for-dmu.patch

This one is for ZFS, which won't be running on RHEL5, so we could drop it. I believe that the SPL code can work around unexported symbols anyway.

+small-fixes-about-jbd.patch
+prune-icache-use-trylock-rhel5.patch
+lustre_iser_max_sectors_tuning_lustre2.0.patch

A couple of minor patches, probably useful for 1.8 also.

The bigger delta exists for ldiskfs patches, but even that is not so large to make it difficult to have a single ldiskfs RPM for 1.8 and 2.1, if we want to do that. However, it is the kernel that would be the big win, IMHO.

[Robert Read (Inactive)]

That's an excellent idea. We could also consider moving the lustre/kernel_patches directory to a separate repository so we could manage a single version for both lustre versions.

[Andreas Dilger]

Moving to patchless server kernels (LU-20) will also fix this issue.