Jian Yu (yujian@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/32888
Subject: LU-11173 kernel: kernel update [SLES12 SP3 4.4.140-94.42]
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 3564d283d8b81b0cc7fd44cc58c0360fbf3e3008
While applying patch blkdev_tunables-3.8-sles12.patch to SLES12 SP3 4.4.140-94.42.1, the following conflict occurred:
--- include/scsi/scsi.h +++ include/scsi/scsi.h @@ -24,7 +24,7 @@ enum scsi_timeouts { * to SG_MAX_SINGLE_ALLOC to pack correctly at the highest order. The * minimum value is 32 */ -#define SCSI_MAX_SG_SEGMENTS 128 +#define SCSI_MAX_SG_SEGMENTS CONFIG_SCSI_MAX_SG_SEGMENTS /* * Like SCSI_MAX_SG_SEGMENTS, but for archs that have sg chaining. This limit
It turns out the definition of SCSI_MAX_SG_SEGMENTS doesn't exist in the new scsi.h. I'm investigating how to resolve the conflict.
Can we kill those patches off? Bull showed those patches don't help for a long time for performance. See LU-20 for details.
Thank you for the guidance, James.
Hi Andreas,
On master branch, the current patch list for SLES12 SP3 is:
raid5-mmp-unplug-dev-sles12sp3.patch dev_read_only-3.9.patch blkdev_tunables-3.9-sles12sp3.patch
The raid5-mmp-unplug-dev-sles12sp3.patch is still needed because it has not been submitted upstream.
The dev_read_only-3.9.patch is no longer needed because it has been replaced by "dm-flakey" module.
The default_max_sectors part in blkdev_tunables-3.9-sles12sp3.patch is no longer needed, but I'm not sure about the default_max_segments part according to the following comments in LU-20:
https://jira.whamcloud.com/browse/LU-20?focusedCommentId=78574&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-78574
Could you please advise if we can just remove blkdev_tunables-3.9-sles12sp3.patch? Thank you.
Actually raid5-mmp-unplug-dev-* was submitted upstream but was rejected. See
https://www.redhat.com/archives/dm-devel/2014-November/msg00004.html
Basically that patch needs a lot more work to do the right thing. Oh how funny. It was Neil Brown that nicked the patch 
Yes, the raid5-mmp patch didn't get accepted. While there is still a race condition with the patch applied, it is definitely much smaller than without the patch at all.
In any case, we haven't supported Lustre+ldiskfs on MD RAID devices for a long time (the MD-RAID rebuild was too slow for very large filesystems or needed dedicated flash devices), and instead we tell people to use ZFS when they want software RAID. So in summary, I don't care a huge amount about that patch anymore.
Note that there are a couple of other kernel patches in the RHEL7 series to improve performance and/or add functionality (mainly quota related), and a new patch incoming for the T10-PI API change. My position is that these are optional patches and people can use them if they want, but we won't accept "required" kernel patches anymore. The Lustre code has to be able to build against the the vanilla kernel, possibly with some reduced functionality, and the ldiskfs module can be built/loaded independently of the main kernel. We've started building the client+server code against the unpatched kernel, and I think that should become part of the required builds for every review patch.
We're getting closer on the remaining major ldiskfs features being included into upstream ext4 as well, and I'd be happy if we could move that further along. The main outlier at this point is the dir_data feature, and many of the remaining ext4 patches are for performance and adding exports to the code for osd-ldiskfs to use.
Thank you for the advice, Andreas.
Do I understand correctly that for the current SLES12 SP3 patch list, we need keep the raid5-mmp patch and can remove the blkdev_tunables patch?
After removing dev_read_only-3.9.patch, sanity test 802 (simulate readonly device) failed as follows:
Lustre: DEBUG MARKER: mkdir -p /mnt/lustre-mds1; mount -t lustre -o rdonly_dev /dev/mapper/mds1_flakey /mnt/lustre-mds1 LDISKFS-fs (dm-3): mounted filesystem with ordered data mode. Opts: user_xattr,errors=remount-ro,no_mbcache,nodelalloc format at osd_handler.c:7368:osd_mount doesn't end in newline Lustre: lustre-MDT0000-osd: not support dev_rdonly on this device LustreError: 14283:0:(obd_config.c:559:class_setup()) setup lustre-MDT0000-osd failed (-95) LustreError: 14283:0:(obd_mount.c:202:lustre_start_simple()) lustre-MDT0000-osd setup error -95 LustreError: 14283:0:(obd_mount_server.c:1902:server_fill_super()) Unable to start osd on /dev/mapper/mds1_flakey: -95 LustreError: 14283:0:(obd_mount.c:1599:lustre_fill_super()) Unable to mount (-95)
Maloo report: https://testing.whamcloud.com/test_sets/c973a2a4-a5f0-11e8-a5f2-52540065bddc
Really. We still missed a dev_read_only case 
That means this test fails for Ubuntu support since it doesn't have the dev_read_only patches.
Jian Yu (yujian@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/33054
Subject: LU-11173 kernel: kernel update [SLES12 SP3 4.4.140-94.42]
Project: fs/lustre-release
Branch: b2_10
Current Patch Set: 1
Commit: a204e2d527d3b6ce588413fd422610c587a340a0
A more newer SLES12 SP3 kernel update is being worked in LU-11255. Let's close this ticket.