From: David Zeuthen <davidz@redhat.com>
Date: Sat, 30 Oct 2010 16:30:19 +0000 (-0400)
Subject: Run scsi_id and ata_id on the scsi_device object
X-Git-Tag: 174~309
X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=commitdiff_plain;h=2938220037862b7698df091a1e5cd45f44132d73

Run scsi_id and ata_id on the scsi_device object

In a multi-initiator setup, the HBA may very well export a SCSI device
for a device that another initiator has already logged into. But since
another initiator has already logged in, the kernel will not create a
block device.

Note that this is also the case for some RAID HBAs - for example, the
LSI 1068 series cards will export a SCSI device for a disk that is in
use by the HBAs RAID engine (no block device will be created here).

Running scsi_id and ata_id on the actual SCSI device means that we can
inquire the capabilities of the device. For example, we can check
whether ID_ATA_FEATURE_SET_SMART and ID_ATA_FEATURE_SET_SMART_ENABLED
is set and, if so, periodically poll the SMART status of the
disk. Even when other initiators has claimed the disk and if the disk
is in use by the RAID engine of the HBA.

Note that we run scsi_id and ata_id on /dev/bsg/* nodes - this is safe
to do because the scsi core guarantees that the bsg device has been
created before the actual add uevent for the scsi_device is emitted.

Since the block device is a direct child of the scsi_device we can
avoid running scsi_id and ata_id again by simply importing the
resulting ID_* properties from the parent.

Signed-off-by: David Zeuthen <davidz@redhat.com>
---

diff --git a/rules/rules.d/60-persistent-storage.rules b/rules/rules.d/60-persistent-storage.rules
index 6449e077a..d3f2f7349 100644
--- a/rules/rules.d/60-persistent-storage.rules
+++ b/rules/rules.d/60-persistent-storage.rules
@@ -6,7 +6,16 @@
 # forward scsi device event to corresponding block device
 ACTION=="change", SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST=="block", ATTR{block/*/uevent}="change"
 
+# from this point on, we don't care about remove envets
+#
 ACTION=="remove", GOTO="persistent_storage_end"
+
+# run scsi_id and ata_id on the actual SCSI device
+SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", ENV{ID_SERIAL}!="?*", ATTR{vendor}=="ATA", IMPORT{program}="ata_id --export $root/bsg/$kernel"
+SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --whitelisted --export --device $root/bsg/$kernel"
+
+# from this point on, only care about block devices
+#
 SUBSYSTEM!="block", GOTO="persistent_storage_end"
 
 # skip rules for inappropriate block devices
@@ -22,6 +31,9 @@ ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"
 KERNEL=="vd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
 KERNEL=="vd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"
 
+# import ata_id/scsi_id data from the scsi_device captured above, if available
+SUBSYSTEMS=="scsi", IMPORT{parent}="ID_*"
+
 # USB devices use their own serial number
 KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="usb", IMPORT{program}="usb_id --export %p"
 # ATA devices with their own "ata" kernel subsystem