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-boun...@centos.org on behalf of nick.jacq...@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>
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
