udevd stop my HDD from spinning down about systemd

[poettering]

These lines are relevant:

May 12 12:08:27 nas systemd-udevd[282449]: sdd: Received inotify event for /dev/sdd.
May 12 12:08:38 nas systemd-udevd[282449]: sdd: device is closed, synthesising 'change' on /sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/0000:02:08.0/0000:05:00.0/0000:06:00.0/0000:07:00.0/host12/port-12:0/end_device-12:0/target12:0:0/12:0:0:0/block/sdd

So udev watches block devices via inotify for IN_CLOSE_WRITE events: i.e. whenever a block device that was opened by userspace for writing is closed, we'll retrigger the device so that the partition table is reread and similar things.

hence, figure out what tool is responsible for opening the block device writable.

udev itself never opens a block device writable, it just probes it in read-only mode. Hence it must be some other component of your OS. Once you fix that, then udev won't do a thing anymore either.

Closing, since this isn't a systemd problem, but some other tool is triggering this.

[zhangyoufu]

This device is not mounted, and this is a headless server with no such userspace program which would open the block device in write mode (except sg_start itself).

strace shows that sg_start opens the HDD in read-write mode by default. After sg_start closes the fd, systemd-udevd rechecks the partition table which triggers unexpected spin-up.

Fortunately, sg_start has an option --readonly, -r which opens the block device in read-only mode. But still, the interaction between sg_start and systemd-udevd worth some documentation.

I opened an issue in sg3_utils asking if it's possible to make sg_start read-only by default.

[mwilck]

Can you check which command run by udev actually causes the call to sd_revalidate_disk? Is it the scsi_id call?

Fortunately, sg_start has an option --readonly, -r which opens the block device in read-only mode.

Right. Looking at it this way, runningn sg_start --stop without --readonly may be considered a user error. Note that the "nuisance spin-up" is actually mentioned in the sg_start man page.

But still, the interaction between sg_start and systemd-udevd worth some documentation.

udevd's close-after-write behavior is documented, although not very prominently. Search for watch in udev(7). If you don't want this, you can set OPTIONS:="nowatch" in a custom udev rule.

This is not the only use case in which udev's watch mechanism is causing unexpected effects. But there are only very few reports of this kind, so it doesn't seem to be a big problem for most users. OTOH, it makes sure that the OS notices partition table changes, which is a nice feature that would be thoroughly missed by users if it didn't exist.

[zhangyoufu]

Can you check which command run by udev actually causes the call to sd_revalidate_disk? Is it the scsi_id call?

Last time I checked via kernel ftrace, userland process was systemd-udevd. Double checked by commenting out scsi_id line in udev rule file, restart systemd-udevd, and execute sg_start --stop, the issue still exists.

[yuwata]

Yeah, we should check if the disk is stopped before running scsi_id or blkid. But how?