[LU-20] patchless server kernel

• Type: Improvement
• Resolution: Fixed
• Priority: Critical
• Affects Version/s: Lustre 2.4.0
• Labels: cea llnl
• Bugzilla ID: 21,524
• Assignee: Oleg Drokin
• Reporter: nasf (Inactive)

Description

Remove Lustre kernel patches to allow Lustre servers to be more easily ported to new kernels, and to be built against vendor kernels without changing the vendor kernel RPMs. There are a number of different patches, each one needs to use equivalent functionality which already exists in the kernel, or work to get the patch accepted upstream.

Corresponding to bugzilla link:
https://bugzilla.lustre.org/show_bug.cgi?id=21524

Issue Links

• is blocked by: LU-8685 Fix JBD2 issue in EL7 Kernels
• is blocking: LU-9761 Add ldiskfs support to dkms for patchless kernel
• is related to: LU-8729 conf-sanity test_84: FAIL: /dev/mapper/mds1_flakey failed to initialize!
• is related to: LU-9339 fix RHEL 7.2 project quota build error
• is related to: LU-2442 metadata performance degradation on current master
• is related to: LU-9698 osd-ldiskfs: unknown symbol error on patched kernel
• is related to: LU-7643 Remove kernel version string from Lustre release field
• is related to: LU-2473 ldiskfs RHEL6.4 support
• is related to: LU-9111 update osd-ldiskfs to not depend on dev_readonly patches
• is related to: LUDOC-83 Patchless Server Doc Changes
• is related to: LU-3406 Submit raid5-mmp-unplug-dev patch upstream
• is related to: LU-433 remove jbd2-jcberr patch from kernel

Comments

[Christopher Morrone (Inactive)]

Peter, I don't think that is how we should look at this ticket. While it is true that the kernel has a bug there that is a problem for lustre, lustre can build and run without that patch. We could, and should, move that patch out of the Lustre tree. That patch is a kernel patch, and should be housed in a kernel repository.

What is really holding up this ticket is still subtask 2, LU-684. The dev_rdonly patch is, as I understand, an entirely Lustre-specific patch for the kernel. It will never be upstreamed, and will always be a burden on the Lustre developers to maintain.

Once we finally finish LU-684, it will be possible to reasonable delete the "lustre/kernel_patches" directory from the Lustre repository, and make a much cleaner separation between building the kernel and building Lustre.

So LU-684 remains the real blocker to calling this ticket complete. But even when it is done, there should still be some minor work to remove lustre/kernel_patches from the tree before this ticket is closed.

[Peter Jones]

In order to go to patchless servers for ldiskfs deployments we need a version of RHEL 7.x which include the fix for the upstream bug "jbd2: incorrect unlock on j_list_lock ". We have been told that this will be available in the near future but at this stage it seems more likely to be available in the 2.10.1 timeframe rather than 2.10.0

[Christopher Morrone (Inactive)]

Oh, sorry, 26220 hasn't landed yet.  I'll just -1 it.

[Christopher Morrone (Inactive)]

Sigh.  That approach is almost entirely impractical when it comes time to do the packaging.  Not only that, it would appear to break the install of the kmp-lustre-tests for builds with ldiskfs but without a patched kernel.  Which is exactly the situation we're trying keep support for.

Looks like someone should open another 2.10 blocker.

 

[James A Simmons]

Chris I have a question. With the patch https://review.whamcloud.com/26220 we can build osd-ldiskfs modules that work with both patched and unpatched kernels without a rebuild. Now if I install osd-ldiskfs modules on a unpatched kernel I do see no dev_read_only missing errors. So the question is how could add a install script in the spec file that can detect a patched kernel and install special osd-ldiskfs module?

[Andreas Dilger]

Yes, the fix for ldiskfs to build against a non-project-quota kernel was landed last week (patch https://review.whamcloud.com/26647 "LU-9339 ldiskfs: Make ldiskfs buildable on kernels with no project quota"), and I'm using this at home as well (RHEL 7.2 kernel).

In fact, with patch https://review.whamcloud.com/26220 "LU-20 osd-ldiskfs: Make readonly patches optional" and weak module support it will be possible to use the same ldiskfs code against a patched and unpatched kernel.

[James A Simmons]

Yes. I'm running with RHEL7 stock kernel right now with latest master and ldiskfs.

[Christopher Morrone (Inactive)]

So just to be 100% clear, ldisk will still be buildable on RHEL7 with stock kernels?

[Andreas Dilger]

Yes, the 2.10 release will be able to build without this feature, even on RHEL.

[Christopher Morrone (Inactive)]

OK, so if ldiskfs can be built on SLES without this feature, then we need a way to also make the feature optional on RHEL. We need to be able to build without the feature if the kernel is not patched to add said feature.

That way we can keep this 10 year goal of being kernel patch free alive. And it is an important goal I think.

I would argue that if that can't be accomplished in time for 2.10, then the LU-4017 feature needs to be disabled altogether until the feature can be optional in the build.

[Bob Glossman (Inactive)]

James,

I very recently asked that exact same question.  Current implementation only supports the feature on el7.   Undetermined at this time if it will be extended to other distros or versions.