https://bugzilla.suse.com/show_bug.cgi?id=1178797 Anton Smorodskyi <anton.smorodskyi@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jack@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c2 Josef Reidinger <jreidinger@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lslezak@suse.com Flags|needinfo?(jreidinger@suse.c |needinfo?(lslezak@suse.com) |om) | --- Comment #2 from Josef Reidinger <jreidinger@suse.com> --- (In reply to Stefan Schubert from comment #1)

Josef, what do you think about it ?

It has nothing to do with bootloader, as bootloader just provide API for setting kernel command line, but real code to set it is in yast2-tune. So maybe Lada can comment it? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c5 --- Comment #5 from Stefan Schubert <schubi@suse.com> --- *** Bug 1179108 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c7 Lukas Ocilka <locilka@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |locilka@suse.com --- Comment #7 from Lukas Ocilka <locilka@suse.com> --- I've found some conflicting pieces of information about this paramter. For sure it's been dropped in some Kernel version, but I'm just not sure about the number. Some write that since 5.4 /elevator/ does not work anymore and that message is there since 5.5. https://github.com/torvalds/linux/commit/85c0a037dc7a1a34d6add49d6eaa2deddbf... https://www.spinics.net/lists/linux-block/msg46493.html Of course, customers WANT to set it somehow, so just simply dropping is not an option. We'll need to add support for configuring that, e.g. by with udev https://unix.stackexchange.com/questions/597314/how-to-change-the-io-policy-... There's another way using sys, but that needs running the system (not in installer) https://unix.stackexchange.com/questions/597314/how-to-change-the-io-policy-... -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c9 Jan Kara <jack@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aherrmann@suse.com Flags|needinfo?(jack@suse.com) | --- Comment #9 from Jan Kara <jack@suse.com> --- elevator= parameter stopped working with transition to blk-mq block layer framework in the kernel (around 5.0 timeframe, not sure exactly, I can find the commit if you're interested). I created jsc#SLE-10853 for updating the docs and release notes, the docs were updated, the release note is still WIP with the docs team :-|. Anyway for the sake of this bug SLE15-SP2 and anything newer doesn't really support elevator= kernel argument. Note that there was a relatively long time frame (between 5.0 and 5.5) when the argument was just silently ignored before we re-added handler for that argument to at least warn users. And we backported this warning to our SLE15-SP2 kernels. WRT other ways of setting the IO scheduler we currently carry udev rules that setup the elevator for each device as appropriate. That is effectively using sysfs and is currently the only way how you can influence which IO scheduler is going to be used for which device. From installer POV the only way I see how it could influence what elevator the installed system is going to use (which is what this yast2 feature is about AFAIU) is that it would modify / add further udev rules tuning the IO scheduler when the system is booting. Or we could change our udev rules to take into account some environment variable or something like that (might be useful for simple setups with single disk). So probably let's start by thinking what feature / experience do we want to provide from the installer POV wrt IO scheduler config (I can imagine anything starting with "nothing" and ending with tool allowing configuring complex set of rules determining IO scheduler for each device - something like nice user-friendly dialogues for configuring udev rules)... I'm adding to CC Andreas Herrmann who was writing the current set of udev rules. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c11 Lukas Ocilka <locilka@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fcrozat@suse.com Flags| |needinfo?(fcrozat@suse.com) | |, | |needinfo?(rtsvetkov@suse.co | |m) --- Comment #11 from Lukas Ocilka <locilka@suse.com> --- It's not YaST who sets the elevator, it's the user/customer. The point here is that our customers might depend (or rather think they depend) on it. YaST offers the UI to set that variable, customers use it and they don't get what they expected. There are obviously two options: 1. removal of the feature or 2. replacing with new functionality (how is an implementation detail). The current solution in /usr/lib/udev/rules.d/60-io-scheduler.rules LGTM, but I'm not the one to decide if that is enough to replace the old functionality. **Frederic, Rado: What do you think? Removal or new implementation?** The good part is that we do not offer that option via AutoYaST directly, but if customer has set this via additional kernel parameters for Bootloader https://github.com/yast/yast-bootloader/blob/master/src/autoyast-rnc/bootloa... then we might need to do some more magic to, e.g., report some warning and remove that option. Some tests contain that value too https://github.com/yast/yast-bootloader/blob/78f31a9f30e42641c1147d199cac103... Anyway, we can also check a bit more out of scope of YaST. Quick GitHub search, for instance says: https://github.com/SUSE/cluster-tools/blob/6a78ee1c86c75d2fc9fb289a5f31c85f8... https://github.com/SUSE/sap-bootcamp/blob/90cca6a0e132c535a046fda84023a53c33... ... there are more sap/cluster projects or branches and I'm unable to evaluiate them well ... Maybe https://github.com/SUSE/doc-slert/blob/3e117f3eb195cd6435750045eb9f7f9bce51e... Maybe https://github.com/SUSE/doc-sle/blob/f59aee9f4eead38b58a3171943b1f35f73aff30... Many places in docu were already adjusted, but I feel that some relevant pieces still mention elevator. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c13 Steffen Winterfeldt <snwint@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS CC| |snwint@suse.com --- Comment #13 from Steffen Winterfeldt <snwint@suse.com> --- The current implementation in 60-io-scheduler.rules skips its own adjustments when elevator is set in cmdline - which is counterproductive at best, IMHO. When I read the above correctly the elevator setting has not been supported by the kernel for quite some time now. This begs the question what people are actually missing. We should (1) remove the elevator setting so at least 60-io-scheduler.rules starts working as intended. And then (2) I agree with Jan in comment 9 that we need to re-think what the expectations of this from the user/customer perspective is. IMHO we should leave this field alone and put a chapter into our SLE handbook. The natural alternative seems to me to control it in the storage-ng module. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c15 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fbui@suse.com) |needinfo?(aherrmann@suse.co | |m) --- Comment #15 from Franck Bui <fbui@suse.com> --- (In reply to Steffen Winterfeldt from comment #14)

Franck, this check for 'elevator' in

/usr/lib/udev/rules.d/60-io-scheduler.rules

should probably also go, or?

Good point, however this rule file is maintained by the kernel team. Andreas, WDYT ? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c17 Andreas Herrmann <aherrmann@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(aherrmann@suse.co | |m) | --- Comment #17 from Andreas Herrmann <aherrmann@suse.com> --- (In reply to Franck Bui from comment #15)

(In reply to Steffen Winterfeldt from comment #14)

...

Franck, this check for 'elevator' in

/usr/lib/udev/rules.d/60-io-scheduler.rules

should probably also go, or?

Good point, however this rule file is maintained by the kernel team.

Andreas, WDYT ?

Depends on whether the rules file is used also with an older kernel still supporting the legacy block layer. (E.g. someone installing an old kernel) Maybe moving the elevator check after the blk-mq udev rule as shown in attachment #844283 is the better approach. OTHO if we are sure the rules file is only used for newer kernels w/o legacy block layer, then not only the elevator check but also the Non-MQ rules can be removed. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c19 Andreas Herrmann <aherrmann@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(aherrmann@suse.co | |m) | --- Comment #19 from Andreas Herrmann <aherrmann@suse.com> --- (In reply to Franck Bui from comment #18)

(In reply to Andreas Herrmann from comment #17)

...

Depends on whether the rules file is used also with an older kernel still supporting the legacy block layer. (E.g. someone installing an old kernel)

Well as a kernel guy, you probably know better than us ;)

Thought more about it. I think keeping the legacy rules (for CFQ and deadline) in there and moving the elevator check after blk-mq rule is the safer approach. In case someone boots an old kernel with legacy block layer support it works as usual.

Also can you please submit your changes to relevant projects ?

I'll do. I am just waiting for some other problem to be settled which also (most likely) requires a change in 60-io-scheduler.rules. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c21 --- Comment #21 from Andreas Herrmann <aherrmann@suse.com> --- (In reply to Anton Smorodskyi from comment #20)

(In reply to Andreas Herrmann from comment #19)

...

(In reply to Franck Bui from comment #18)

...

(In reply to Andreas Herrmann from comment #17)

...

Depends on whether the rules file is used also with an older kernel still supporting the legacy block layer. (E.g. someone installing an old kernel)

Well as a kernel guy, you probably know better than us ;)

Thought more about it. I think keeping the legacy rules (for CFQ and deadline) in there and moving the elevator check after blk-mq rule is the safer approach. In case someone boots an old kernel with legacy block layer support it works as usual.

maybe we could at least add some informational comment which would warn user that this check make sense only till kernel version X ?

Good idea. Will do that. FYI, kernel v5.0 removed legacy IO path (and elevator parameter stopped working), with kernel v5.4 elevator parameter was removed, kernel v5.5 added a warning if elevator parameter was still specified. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c24 Steffen Winterfeldt <snwint@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED CC| |taroth@suse.com Resolution|--- |FIXED --- Comment #24 from Steffen Winterfeldt <snwint@suse.com> --- Ok, I've removed the yast setting and will close this bug. BTW, the SLE docs mention the elevator setting here: https://github.com/SUSE/doc-sle/blob/master/xml/tuning_storagescheduler.xml#... Maybe that needs adjusting - I'm adding Tanja from the documentation people. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1178797 https://bugzilla.suse.com/show_bug.cgi?id=1178797#c26 --- Comment #26 from Swamp Workflow Management <swamp@suse.de> --- SUSE-RU-2021:0005-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1168036,1178797 CVE References: JIRA References: Sources used: SUSE Linux Enterprise Module for Basesystem 15-SP2 (src): yast2-tune-4.2.5-3.5.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.