udev patterns are shell globs, so nvme[0-9]*n[0-9]* also matched every partition. Partitions have no queue/scheduler, and udev logged a "Could not chase sysfs attribute" for each one at boot. Restrict the match to SUBSYSTEM block with DEVTYPE disk, which also keeps mmcblk boot areas and NVMe multipath nodes out. Reword the comment: kyber targets a read latency rather than bounding it, and the kernel's default choice depends on the device rather than being a fixed NVMe versus everything-else split. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
9 lines
653 B
Plaintext
9 lines
653 B
Plaintext
# Kyber keeps reads in their own queue and throttles the depth it submits to
|
|
# hold a 2ms read latency target, so interactive reads keep flowing while a
|
|
# large build, copy, or package upgrade floods the disk with writes. The
|
|
# kernel's own pick (none or mq-deadline, depending on the device) does not
|
|
# regulate latency once the queue fills. Whole disks only: partitions have no
|
|
# scheduler of their own, and zram is memory with nothing to schedule. Zoned
|
|
# btrfs disks are moved back to mq-deadline by 64-btrfs-zoned.rules.
|
|
ACTION=="add|change", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", KERNEL=="nvme*|sd*|mmcblk*|vd*", ATTR{queue/scheduler}="kyber"
|