summaryrefslogtreecommitdiff
path: root/udev.conf
diff options
context:
space:
mode:
authorDavid Zeuthen <davidz@redhat.com>2010-10-30 12:30:19 -0400
committerDavid Zeuthen <davidz@redhat.com>2010-10-30 13:04:35 -0400
commit2938220037862b7698df091a1e5cd45f44132d73 (patch)
tree23e19f2fa70d2d3bd035bdb3938efaa6e94df703 /udev.conf
parent6992637e3165d433353c996aad16c8d141b00845 (diff)
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>
Diffstat (limited to 'udev.conf')
0 files changed, 0 insertions, 0 deletions