nixos/iosched: init module

[illdefined]

Description of changes

This module introduces the following options to set I/O schedulers for block devices and generates appropriate udev rules:

• hardware.block.defaultScheduler: Default scheduler for all block devices.
• hardware.block.defaultSchedulerRotational: Default scheduler for rotational drives, such as hard drives.
• hardware.block.scheduler: Schedulers for specific block devices.

This solves #57577. My personal motivation is that I often run workloads that do not perform well with the default scheduler and I would like to have a way to override it without writing individual udev rules for simple cases.

hardware.block.scheduler is an attribute set assigning schedulers by device name pattern. Using an attrset limits its use to non‐overlapping patterns. Overlapping patterns could be supported by instead using a list of attrsets, but I believe that users requiring these are served better by producing their own custom udev rules.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Atemu]

This is something I think NixOS needs.

The diff LGTM and is very high quality I might add.

Could you go into detail what testing you have done on this? A NixOS test would also be amazing but not required.

One thing I was a little unsure of was that we build bfq as a module and don't load it by default but the kernel appears to just load the module when bfq is asked for.

[illdefined]

This is something I think NixOS needs.

The diff LGTM and is very high quality I might add.

Thank you!

Could you go into detail what testing you have done on this? A NixOS test would also be amazing but not required.

I have been using this module as part of my Nix files with the following configuration since mid of last year without any issues:

hardware.block = {
  defaultScheduler = "kyber";
  defaultSchedulerRotational = "bfq";
  scheduler = {
    "mmcblk*" = "bfq";
  };
};

Testing this in a virtualised environment could be tricky, but I’ll think of something.

I suppose that providing a basic configuration and verifying that the generated udev rules are correct would be a good start, but it might be nice to check if the settings are actually applied to block devices.

[illdefined]

I modified the module to reject values containing a line break, because these are not permitted within udev rules.

I also added a test to check a reasonable module configuration results in a syntactically and semantically correct udev rule set as verified by udevadm verify --no-style and that these rules are applied correctly to various block devices.

[Atemu]

I didn't give it very thorough testing because the code looks very good to me and the NixOS test gives me confidence that it does work as expected.

The basic functionality works and there isn't anything obviously wrong with it. Should any issues crop up, we can fix them later.

Amazing work, thank you :)

[Atemu]

👌

This could perhaps be made available as a type or something as this should be something that is generally useful in other modules/user config.

[illdefined]

Do you think it might be useful to have a generic framework for representing udev rules in Nix?

[Atemu]

That sounds like a good idea to me, though not necessarily a very high priority.

[nixpkgs-ci]

Successfully created backport PR for release-24.11:

• [Backport release-24.11] nixos/iosched: init module #385016

[Atemu]

Ah one minor thing I missed: This should have a release note!

I consider this module to be useful to many people, so they should be made aware that it exists now.

[Atemu]

Ah, one thing I noticed in actual deployment is that this affects loop devices which probably shouldn't have an iosched?
I'm actually not quite sure in that regard. Perhaps it can make sense to have a nested queue in some cases?

It's easy enough to disable using the provided options but perhaps the module should handle that case somehow; either through default config or through documentation.

[illdefined]

Ah, one thing I noticed in actual deployment is that this affects loop devices which probably shouldn't have an iosched? I'm actually not quite sure in that regard. Perhaps it can make sense to have a nested queue in some cases?

It's easy enough to disable using the provided options but perhaps the module should handle that case somehow; either through default config or through documentation.

I’ll prepare a PR.