Systemd-udevd Not Applying ATTR To Block Device At Boot

Home » CentOS » Systemd-udevd Not Applying ATTR To Block Device At Boot
CentOS 1 Comment

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

# udevadm info -q all -a /dev/sda

looking at device ‘/devices/pci0000:00/0000:00:03.0/virtio0/host0/target0:0:1/0:0:1:0/block/sda’:
KERNEL==”sda”
SUBSYSTEM==”block”
DRIVER==””
ATTR{ro}==”0″
ATTR{size}==”104857600″
ATTR{stat}==” 14877 938 923845 15717 2732 310 82984 4328 0 9685 20033″
ATTR{range}==”16″
ATTR{discard_alignment}==”0″
ATTR{events}==””
ATTR{ext_range}==”256″
ATTR{events_poll_msecs}==”-1″
ATTR{alignment_offset}==”0″
ATTR{badblocks}==””
ATTR{inflight}==” 0 0″
ATTR{removable}==”0″
ATTR{capability}==”50″
ATTR{events_async}==””

looking at parent device ‘/devices/pci0000:00/0000:00:03.0/virtio0/host0/target0:0:1/0:0:1:0’:
KERNELS==”0:0:1:0″
SUBSYSTEMS==”scsi”
DRIVERS==”sd”
ATTRS{rev}==”1 ”
ATTRS{type}==”0″
ATTRS{scsi_level}==”7″
ATTRS{model}==”PersistentDisk ”
ATTRS{state}==”running”
ATTRS{unpriv_sgio}==”0″
ATTRS{queue_type}==”none”
ATTRS{iodone_cnt}==”0x478f”
ATTRS{iorequest_cnt}==”0x478f”
ATTRS{device_busy}==”0″
ATTRS{evt_capacity_change_reported}==”0″
ATTRS{timeout}==”30″
ATTRS{evt_media_change}==”0″
ATTRS{ioerr_cnt}==”0x0″
ATTRS{queue_depth}==”256″
ATTRS{vendor}==”Google ”
ATTRS{evt_soft_threshold_reached}==”0″
ATTRS{device_blocked}==”0″
ATTRS{evt_mode_parameter_change_reported}==”0″
ATTRS{evt_lun_change_reported}==”0″
ATTRS{evt_inquiry_change_reported}==”0″
ATTRS{dh_state}==”detached”
ATTRS{iocounterbits}==”32″
ATTRS{inquiry}==””
ATTRS{vpd_pg80}==””
ATTRS{vpd_pg83}==””
ATTRS{eh_timeout}==”10″

looking at parent device ‘/devices/pci0000:00/0000:00:03.0/virtio0/host0/target0:0:1’:
KERNELS==”target0:0:1″
SUBSYSTEMS==”scsi”
DRIVERS==””

looking at parent device ‘/devices/pci0000:00/0000:00:03.0/virtio0/host0’:
KERNELS==”host0″
SUBSYSTEMS==”scsi”
DRIVERS==””

looking at parent device ‘/devices/pci0000:00/0000:00:03.0/virtio0’:
KERNELS==”virtio0″
SUBSYSTEMS==”virtio”
DRIVERS==”virtio_scsi”
ATTRS{device}==”0x0008″
ATTRS{features}==”0110000000000000000000000000010000000000000000000000000000000000″
ATTRS{status}==”0x00000007″
ATTRS{vendor}==”0x1af4″

looking at parent device ‘/devices/pci0000:00/0000:00:03.0’:
KERNELS==”0000:00:03.0″
SUBSYSTEMS==”pci”
DRIVERS==”virtio-pci”
ATTRS{irq}==”11″
ATTRS{subsystem_vendor}==”0x1af4″
ATTRS{broken_parity_status}==”0″
ATTRS{class}==”0x000000″
ATTRS{driver_override}==”(null)”
ATTRS{consistent_dma_mask_bits}==”64″
ATTRS{dma_mask_bits}==”64″
ATTRS{local_cpus}==”3″
ATTRS{device}==”0x1004″
ATTRS{enable}==”1″
ATTRS{msi_bus}==””
ATTRS{local_cpulist}==”0-1″
ATTRS{vendor}==”0x1af4″
ATTRS{subsystem_device}==”0x0008″
ATTRS{numa_node}==”-1″
ATTRS{d3cold_allowed}==”0″

looking at parent device ‘/devices/pci0000:00’:
KERNELS==”pci0000:00″
SUBSYSTEMS==””
DRIVERS==””

# udevadm info -q all -a /dev/sdb

looking at device ‘/devices/pci0000:00/0000:00:04.0/virtio1/host1/target1:0:1/1:0:1:0/block/sdb’:
KERNEL==”sdb”
SUBSYSTEM==”block”
DRIVER==””
ATTR{ro}==”0″
ATTR{size}==”786432000″
ATTR{stat}==” 219 0 12776 101 16 0 4096 63 0 66 164″
ATTR{range}==”16″
ATTR{discard_alignment}==”0″
ATTR{events}==””
ATTR{ext_range}==”256″
ATTR{events_poll_msecs}==”-1″
ATTR{alignment_offset}==”0″
ATTR{badblocks}==””
ATTR{inflight}==” 0 0″
ATTR{removable}==”0″
ATTR{capability}==”50″
ATTR{events_async}==””

looking at parent device ‘/devices/pci0000:00/0000:00:04.0/virtio1/host1/target1:0:1/1:0:1:0’:
KERNELS==”1:0:1:0″
SUBSYSTEMS==”scsi”
DRIVERS==”sd”
ATTRS{rev}==”1 ”
ATTRS{type}==”0″
ATTRS{scsi_level}==”7″
ATTRS{model}==”EphemeralDisk ”
ATTRS{state}==”running”
ATTRS{unpriv_sgio}==”0″
ATTRS{queue_type}==”none”
ATTRS{iodone_cnt}==”0x141″
ATTRS{iorequest_cnt}==”0x141″
ATTRS{device_busy}==”0″
ATTRS{evt_capacity_change_reported}==”0″
ATTRS{timeout}==”30″
ATTRS{evt_media_change}==”0″
ATTRS{ioerr_cnt}==”0x0″
ATTRS{queue_depth}==”1024″
ATTRS{vendor}==”Google ”
ATTRS{evt_soft_threshold_reached}==”0″
ATTRS{device_blocked}==”0″
ATTRS{evt_mode_parameter_change_reported}==”0″
ATTRS{evt_lun_change_reported}==”0″
ATTRS{evt_inquiry_change_reported}==”0″
ATTRS{dh_state}==”detached”
ATTRS{iocounterbits}==”32″
ATTRS{inquiry}==””
ATTRS{vpd_pg80}==””
ATTRS{vpd_pg83}==””
ATTRS{eh_timeout}==”10″

looking at parent device ‘/devices/pci0000:00/0000:00:04.0/virtio1/host1/target1:0:1’:
KERNELS==”target1:0:1″
SUBSYSTEMS==”scsi”
DRIVERS==””

looking at parent device ‘/devices/pci0000:00/0000:00:04.0/virtio1/host1’:
KERNELS==”host1″
SUBSYSTEMS==”scsi”
DRIVERS==””

looking at parent device ‘/devices/pci0000:00/0000:00:04.0/virtio1’:
KERNELS==”virtio1″
SUBSYSTEMS==”virtio”
DRIVERS==”virtio_scsi”
ATTRS{device}==”0x0008″
ATTRS{features}==”0100000000000000000000000000010000000000000000000000000000000000″
ATTRS{status}==”0x00000007″
ATTRS{vendor}==”0x1af4″

looking at parent device ‘/devices/pci0000:00/0000:00:04.0’:
KERNELS==”0000:00:04.0″
SUBSYSTEMS==”pci”
DRIVERS==”virtio-pci”
ATTRS{irq}==”10″
ATTRS{subsystem_vendor}==”0x1af4″
ATTRS{broken_parity_status}==”0″
ATTRS{class}==”0x000000″
ATTRS{driver_override}==”(null)”
ATTRS{consistent_dma_mask_bits}==”64″
ATTRS{dma_mask_bits}==”64″
ATTRS{local_cpus}==”3″
ATTRS{device}==”0x1004″
ATTRS{enable}==”1″
ATTRS{msi_bus}==””
ATTRS{local_cpulist}==”0-1″
ATTRS{vendor}==”0x1af4″
ATTRS{subsystem_device}==”0x0008″
ATTRS{numa_node}==”-1″
ATTRS{d3cold_allowed}==”0″

looking at parent device ‘/devices/pci0000:00’:
KERNELS==”pci0000:00″
SUBSYSTEMS==””
DRIVERS==””

One thought on - Systemd-udevd Not Applying ATTR To Block Device At Boot

  • 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

     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>

LEAVE A COMMENT