I suppose it would help if I posted relevant version info (sorry about that...)

CentOS Linux release 7.4.1708 (Core) @ 3.10.0-693.11.6.el7.x86_64 systemd-219-42.el7_4.4.x86_64

$ modinfo virtio_scsi filename: /lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/drivers/scsi/virtio_scsi.ko.xz license: GPL description: Virtio SCSI HBA driver rhelversion: 7.4 srcversion: A80DAE9007C7FCF3DDD1501 alias: virtio:d00000008v* depends: virtio,virtio_ring intree: Y vermagic: 3.10.0-693.11.6.el7.x86_64 SMP mod_unload modversions signer: CentOS Linux kernel signing key sig_key: 2C:BC:98:70:54:63:43:CA:3A:E1:20:C2:BC:EB:98:44:01:95:59:62 sig_hashalgo: sha256

I'm happy to provide any other relevant info if needed! Thanks again!

Nick

On 1/31/18, 12:49 AM, "CentOS on behalf of Nick.Jacques" <centos-bounces@centos.org on behalf of Nick.Jacques@target.com> wrote:

Hi everyone,

I have a udev rule file that contains a singular rule:

SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_VENDOR}=="*Google*", ENV{DEVTYPE}=="disk", ATTR{queue/scheduler}:="noop"

When I use a Google Cloud instance and boot it, things work as expected and /dev/sda (a persistent disk) uses the noop scheduler. If the instance also has a Local SSD type disk, however, the change in scheduler is not applied. This is a bit academic, because the Local SSD device uses noop by default (somehow, I don’t see any udev rules for setting this outside of my own). But, for instance, if I set the scheduler in the udev rules to “cfq,” at boot, /dev/sda will use cfq and /dev/sdb will use noop.

If I run udevadm trigger after boot, then /dev/sdb will use cfq. So, it appears that at boot time, for some reason, my scheduler is not being applied to /dev/sdb.

I’ve tried a handful of things:

- changing the order of my udev rule file: I’ve tried 10-, 90-, and 99- prefixes. My rule file is in /etc/udev/rules.d/. - using ATTR{queue/scheduler}:="noop" and ATTR{queue/scheduler}="noop" (both the = and := operator) - searching the internet for all kinds of variations on “udev rule not applying at boot”

but so far, I’ve come up empty-handed. The only thing I can think of is that I am hitting some sort of race condition and udev is unable to set the ATTR in /sys, but I’m not sure how I can confirm this.

Below are dumps from udevadm of the block devices, /dev/sda (a Google Cloud persistent disk that is my root partition) and /dev/sdb (a Google Cloud ephemeral disk [local SSD] that is mounted at /local-ssd).

Thanks in advance for any assistance!

Nick

< trimmed udevadm output>