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.