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
Attachments
Issue Links
- is blocked by
-
LU-8685 Fix JBD2 issue in EL7 Kernels
-
- Resolved
-
- is blocking
-
LU-9761 Add ldiskfs support to dkms for patchless kernel
-
- Resolved
-
- is related to
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
LU-7643
Remove kernel version string from Lustre release field
-
- Resolved
-
-
LU-2473 ldiskfs RHEL6.4 support
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- is related to
-
LU-3406
Submit raid5-mmp-unplug-dev patch upstream
-
- Resolved
-
-
-
- Resolved
-
- mentioned in
-
Page Loading...
Activity
How many tests actually use the dev_rdonly/dm-flakey functionality?
If it is small, perhaps the best path forward is to simply disable those tests until LU-684 is complete. That would allow us to unblock this ticket, LU-20.
kmod-lustre-2.9.58_57_gc252b3b_dirty-1.el7.x86_64.rpm
lustre-iokit-2.9.58_57_gc252b3b_dirty-1.el7.x86_64.rpm
kmod-lustre-osd-ldiskfs-2.9.58_57_gc252b3b_dirty-1.el7.x86_64.rpm
lustre-osd-ldiskfs-mount-2.9.58_57_gc252b3b_dirty-1.el7.x86_64.rpm
kmod-lustre-tests-2.9.58_57_gc252b3b_dirty-1.el7.x86_64.rpm
lustre-resource-agents-2.9.58_57_gc252b3b_dirty-1.el7.x86_64.rpm
lustre-2.9.58_57_gc252b3b_dirty-1.el7.x86_64.rpm
lustre-tests-2.9.58_57_gc252b3b_dirty-1.el7.x86_64.rpm
lustre-debuginfo-2.9.58_57_gc252b3b_dirty-1.el7.x86_64.rpm
The ext4 source can be founded at
/usr/src/debug/kernel-3.10.0-514.21.1.el7/linux-3.10.0-514.21.1.el7.x86_64/fs/ext4/*
which is provided kernel-debug-debuginfo-*. If you look at the LB_EXT4_SRC_DIR macro in lustre-build-ldiskfs.m4 you will see it does the right thing by default.
James, what are result rpms? did you have kmod-lustre-osd-ldiskfs? I don't see where in your steps include the ext4 sources
Oh, I was confused for a moment and thought that LU-8685 was the LU-684 blocker...but no, it is LU-8729 that blocks LU-684. Now I really don't understand why people though LU-8685 was a blocker for this ticket.
As far as I can tell we're still in the same spot as always: we need LU-684 finished. The 26220 patch is just a temporary hack to ease a packaging/distribution issue because LU-684 has not yet been completed. But 26220 will not let us close this ticket.
Actually its the fix for LU-8685 that has now landed for RHEL7. We no longer need the patch jbd2-fix-j_list_lock-unlock-3.10-rhel7.patch !!! We still need 26220 so osd-ldiskfs will work properly with patch-less kernels. At LUG it was brought up if the lustre tree needs to be patched to build ldiskfs with just standard RHEL kernel rpms. I tried it out and building just works out of the box with patch-less kernels. All I did was
rpm -ivh kernel-devel-3.10.0-514.21.1.el7.x86_64.rpm
If you want to build ldiskfs just do:
rpm -ivh kernel-debuginfo-common-x86_64-3.10.0-514.21.1.el7.x86_64.rpm
cd ~/lustre-release
sh ./autogen.sh
./configure --with-linux=/usr/src/kernels/3.10.0-514.21.1.el7.x86_64
make rpms
install lustre rpms and reboot
I gave the above example for those people like me that have multiple entries in /usr/src/kernel.
That is all that is needed now. We have arrived 
In any event, hopefully the James' revelation that the RHEL kernel is now shipping with the fix means that we can drop change 26220 and just finish this ticket?
Until that patch (http://review.whamcloud.com/23050 from
LU-8685) is included into RHEL7, we will continue to patch the RHEL kernel shipped with Lustre to fix that bug.
I don't understand that logic at all. A patched kernel could have been built completely external to the Lustre tree and allowed us to continue forward with completing this ticket. I really don't understand why this was deemed as a blocker, or had to happen sequentially.
Maybe I'll restate what I think the goal of this ticket really is: Elminate the need for a "Lustre kernel" by eliminating all of the Lustre specific kernel patches (ignoring ldiskfs).
The jbd2 fix, while effecting lustre, is not necessarily lustre specific. Therefore it does not need to be living in lustre/kernel_patches, and we don't need infrastructure in Lustre's main build system to pause in the middle of building lustre to go patch, build, and package a kernel. Instead patching, build, and packaging the kernel can be a completely external process that takes place before, and independantly of each lustre build.
Thats the goal. Nothing that I can see really stands in the way of that goal, unless I'm missing something (and I did read LU-8685).
Great news!!!!! A new RHEL7.3 kernel has been released and it have the jbd2 fix. Time to move to kernel-3.10.0-514.21.1.el7. Patchless servers are again within are grasp.
Per Peter's previous comment:
we need a version of RHEL 7.x which include the fix for the upstream bug "jbd2: incorrect unlock on j_list_lock "
Until that patch (http://review.whamcloud.com/23050 from LU-8685) is included into RHEL7, we will continue to patch the RHEL kernel shipped with Lustre to fix that bug.
Of course, it is possible for anyone to use an unpatched kernel today with ZFS, or to build and run Lustre with a RHEL6 kernel, and this has been true for a couple of releases at least. The presence of kernel patches in the Lustre tree doesn't prevent that. While Intel will continue to apply the kernel patches until such a time that LU-684 and LU-8685 are fixed, it doesn't prevent others from building their Lustre RPMs differently.
All of the recovery-* tests depend on this functionality to some extent, to allow clients to submit writes to the server that are dropped deterministically before the server restarts.
Note there is no reason that the presence of the dev-rdonly patch in our kernel prevents people from building patchless kernels. We need that for the testing ldiskfs, but it is not needed for production with either ldiskfs or ZFS. Note that if you want project quota support for ldiskfs then kernel patches are needed regardless (project quota for ZFS will similarly need ZFS to be patched).