The “rescan-scsi-bus.sh” can be used to scan new LUNs in a CentOS/RHEL machine. When ‘rescan-scsi-bus.sh -i’ is run, script execute as well a LIP_RESET (ISSUE_LIP) which may cause a disruption in I/O on the server and even cause an outage in case of a system running on heavy load.
What is LIP (Loop Initialization Protocol)?
LIP scans the interconnect and causes the SCSI layer to be updated to reflect the devices currently on the bus. A LIP is, essentially, a bus reset, and will cause device addition and removal. This procedure is necessary to configure a new SCSI target on a Fibre Channel interconnect. Bear in mind that issue_lip is an asynchronous operation. The command may complete before the entire scan has completed.
What LIP Reset may cause?
Loop Initialization Protocol method to scan the HBA’s can cause delay and I/O timeouts if the HBA/Device is in use and can also remove devices unexpectedly. Hence performing the scan using this method is not recommended on any production server where the SAN Devices are already configured in use. This type of scan is recommended on a newly built server to scan all the LUNS/Devices. LIP is normally executed when Server boot.
When to use issu_lip
Please use standard rescan-scsi-bus.sh command without -i FLAG, rescan-scsi-bus.sh will only ‘scan’ for new LUNs. Please pay maximum attention when executing rescan-scsi-bus.sh -i on Live/Production Environment, this may cause serious issues.
The issue can be even worse when rescan-scsi-bus.sh is executed on actual RAC Node or any Clustering Software which use Eviction Process, this is due to I/O activity which will be blocked on Node where rescan-scsi-bus.sh -i is executed causing even disk-heartbeat fail to write ‘heartbeat information’.
LIP reset can be also achieved without rescan-scsi-bus.sh -i, using the command:
# echo "1" > /sys/class/fc_host/host/issue_lip
This method is not recommended. The LIP command is asynchronous, so this command may return before the LIP operation is completed. You must monitor the /var/log/messages system log to determine when the LIP operation has completed. This is essentially a bus reset, so any in-flight I/O operations may be disrupted. Please use the rescan-scsi-bus.sh script instead.
When new LUNs is need to be discovered, you can execute:
# echo "1" > /sys/class/fc_host/host/issue_lip
This should help to get new LUNs to appear on the system, without the need to execute a rescan-scsi-bus.sh -i command.
This method is not recommended. The LIP command is asynchronous, so this command may return before the LIP operation is completed. You must monitor the /var/log/messages system log to determine when the LIP operation has completed. This is essentially a bus reset, so any in-flight I/O operations may be disrupted. Please use the rescan-scsi-bug.sh script instead.
Conclusion
When rescan-scsi-bus.sh -i needs to be really executed on the Production Environment please stop all applications/database instances and then follow with rescan-scsi-bus.sh -i. The most safer way would be just planned Server Reboot as when Server Boot-in LIP reset is executed automatically.
Please also keep in mind that rescan-scsi-bus.sh -i does not need to be executed when a multipath path is lost, it will be recovered when back-end Storage Path will be restored (this is done by path_checker option in multipath.conf).