Re: qla2xxx: automatically rescan removed luns.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13-11-26 11:06 AM, Benjamin ESTRABAUD wrote:
On 25/11/13 17:17, Ewan Milne wrote:
On Mon, 2013-11-25 at 15:37 +0000, Benjamin ESTRABAUD wrote:
Hi,

Using the qla2xxx driver from Linux 3.10.1 (release), if a LUN from the
target side (multiple drives exported over a LIO IBlock qla2xxx export)
is removed at the LIO level, the initiator side will not automatically
detect that this LUN was removed.

All commands to this LUN will fail (sg_inq, read, writes) but the
qla2xxx will never kick the drive out.

If another drive was to be exported on the target side using the same
lun as the previously removed drive, commands sent to the same block id
would now work again but be sent to the new LUN.

I tried to echo "- - -" in the scsi_host sysfs "scan" file corresponding
to the FC port. This worked to detect new LUNs but not to "clear"
removed ones.

I tried issuing a lip_reset on both sides, but no change.

Looking through Google, I realized that, on RedHat, a /proc/scsi/qla2xxx
virtual FS exists which allows to send a "scsi-qlascan" command to the
driver that apparently can detect removed LUNs. Unfortunately I don't
have this FS visible on my Linux kernel, and I made sure /proc/scsi was
enabled.

The only way I found was to "echo 1 > /sys/block/sdX/device/delete" to
the stale device (that corresponds to the removed LUN from the target
side), then replace the removed LUN on the target side before finally
issuing a "scan" command on the initiator side.

Am I missing something here? Is there a way to rescan a Qlogic FC port
using the "qla2xxx" driver from the official, stock kernel?

Hi,

Thank you very much for your reply, this is much appreciated.

The kernel does not contain support for removing devices automatically
during a subsequent rescan.

I thought that it used to with older kernels, is that possible (was this a
recent change of behaviour)? It does, however, remove devices which port or
connection has gone offline (pulled SAS disk, FC target inaccessible because of
a disconnected cable).

Looking into it, the 'echo "- - -" > /sys/class/scsi_host/hostX/scan' scan
command does issue a request_lun command (at least in SAS, used a target on
which I could trace incoming commands).

When ran and a new LUN is detected, Linux does the right thing and adds the device.

When ran and a LUN is gone, it does nothing, as you explained above.


   You have to delete them individually.
Noted.

You can, however, update the properties detected when scanning a device
(e.g. disk capacity) by scanning the individual device in sysfs.  For
SCSI devices, there is a "rescan" capability, e.g.

echo 1> /sys/devices/<pci device path>/host0/target0:0:0/0:0:0:0/rescan

I used that rescan feature that I didn't know about and it's *very* useful,
thank you!!

*Very* recent kernels contain a udev notification mechanism when a SCSI
device reports a Unit Attention, so you can have udev rules like:

ACTION=="change", SUBSYSTEM=="scsi", \
ENV{SDEV_UA}=="INQUIRY_DATA_HAS_CHANGED", TEST=="rescan", \
ATTR{rescan}="x"

ACTION=="change", SUBSYSTEM=="scsi", \
ENV{SDEV_UA}=="CAPACITY_DATA_HAS_CHANGED", TEST=="rescan", \
ATTR{rescan}="x"

ACTION=="change", SUBSYSTEM=="scsi", \
ENV{SDEV_UA}=="THIN_PROVISIONING_SOFT_THRESHOLD_REACHED", \
TEST=="rescan", ATTR{rescan}="x"

ACTION=="change", SUBSYSTEM=="scsi", \
ENV{SDEV_UA}=="MODE_PARAMETERS_CHANGED", TEST=="rescan", \
ATTR{rescan}="x"

ACTION=="change", SUBSYSTEM=="scsi", \
ENV{SDEV_UA}=="REPORTED_LUNS_DATA_HAS_CHANGED", \
RUN+="<script to scan devices> $env{DEVPATH}"

...

That sounded promising, unfortunately the version we use (3.10.y branch) doesn't
have this yet.

A script to scan devices can use the devpath of the SCSI device
reporting the Unit Attention to perform the desired action.  If you
just want to scan the target port, something like this might work,
although it is a little clumsy...

Thank you very much for that script, that gives me a pretty good idea of what
needs to be done here.

#!/bin/sh -e

HOST_PATH1=`echo $1 | awk '{print substr($1,0,index($1,"/target")-1)}'`
HOST_PATH2="scsi_host/host"`echo $1 | awk
'{split(substr($1,index($1,"target")),a,"/"); split(a[2],b,":"); print
b[1]}'`"/scan"

SCAN_STRING=`echo $1 | awk '{split(substr($1,index($1,"target")),a,"/");
split(a[2],b,":"); print b[2],b[3],"-"}'`

echo $SCAN_STRING > "/sys/"$HOST_PATH1"/"$HOST_PATH2

Or, "rescan-scsi-bus.sh" from (I think) sg3_utils might do what you
want.  Beware of running shell scripts from udev rules, however, as
that doesn't scale well in large configurations.

"rescan-scsi-bus.sh" did detect new LUN, but apparently not removed ones.
However I need to test it on a system with a compatible bash shell as I wasn't
able to run the script without errors.

Did you try the rescan-scsi-bus.sh from sg3_utils v 1.37 or
earlier? The reason I ask is that a fair amount of work
was done on the rescan-scsi-bus.sh found in version 1.37
including syncing with Kurt Garloff's version 1.57 plus
patches from Hannes Reinecke and Sean Stewart.

Doug Gilbert

-Ewan


Regards,
Ben.

Thank you very much in advance for your help!

Regards,

Ben - MPSTOR
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux