Red Hat Bugzilla – Bug 236576
Scant information regarding SCSI bus scanning and devices hot adding/removal
Last modified: 2014-08-04 18:17:33 EDT
Description of problem:
There are 2 Redhat KB articles that cover the topic of scanning the SCSI bus and
hot adding and removing of devices:
Both of them specify that the operation isn't guaranteed to work and not corrupt
This information isn't satisfactory for corporate RHEL customers. E.g. our
customer (who has quite a large RHEL deployment) has a IBM x346 production
server with SerweRAID 7k controller running RHEL4U4 and needs to hot-add a SCSI
Using IBM Director the disk has been added as a logical drive and initialized,
but the OS didn't discover the new device.
The KB information doesn't look encouraging and gives no hint as to what
hardware can handle the scsi rescanning/device addition, and what hardware will
IMO the KB article should be updated with a list of hardware configurations on
which SCSI scanning/adding/removal has been tested to work correctly, and
configurations on which it has failed in Redhat's labs.
Only Redhat has sufficient hardware resources to do such extensive testing.
Any updates on this?
Hotplugging of disk drives is a pretty basic expectation from an enterprise
This is a more complicated matter than the kbase covers. I'll reply to your
comments in line.
> Both of them specify that the operation isn't guaranteed to work
Correct, as many drivers, such as third party modules can influence how this
works. Multipathing and fiber switches between the storage and the host machine
may influence the ability to be able to reliably hot add devices.
> not corrupt data.
If you have a pending scsi write to a device on the chain, you issue a scsi
reset down the chain while the device is pending a write() or a read(), there is
no guarantee that this data will be synced to the disk before the scsi device
reset is done.
It is also possible that multiple host controllers are connected to a single
scsi bus chain (not common, but it has been seen in production) rescanning the
bus which is initiated by a single controller will cause the other scsi bus
controller to reset, losing possible writes queued on the controllers internal
> This information isn't satisfactory for corporate RHEL customers.
> E.g. our customer (who has quite a large RHEL deployment) has a IBM x346
> production server with SerweRAID 7k controller running RHEL4U4 and needs to
> hot-add a SCSI drive.
I would strongly reccomend that you test this kind of change to your server
infrastructure on your staging systems first before deploying to your production
systems, testing testing and more testing.
If you feel that this is a feature that you'd like to see in Red Hat Enterprise
Linux, please contact Red Hat Support (or your TAM ) and raise a feature request
citing this bugzilla.
I think it would be a good idea to copy-paste your explanation into the kb
articles in question since this makes some things more clear and is a good thing.
That said, you explanation covers problems with multipathing and shared storage
What about a simple case where the device is simply hot-added to a dedicated
box, and all devices on the SCSI chain are idle at the moment (e.g. all services
are stopped and filesystems are synced)?
Whatever the answer, it would be a good idea to add more info to kb to clarify
Removing automation notification
question satisfactorily answered by wmealing.
as for suggestion re: kbase, please use the rating buttons (i.e. "How well did
this entry answer your question?") to notify the specific kbase writer.
closing this bug as NOTABUG.