Stale devices in sysfs
Quoted 84 lines · James Bottomley
From: James Bottomley <[email protected]>
Subject: Re: Stale devices in sysfs
To: "Ahmed A" <[email protected]>
Cc: [email protected]
Date: Thursday, March 26, 2009, 10:41 AMQuoted 3 lines · Ahmed A
Hello,
I have a two port FC hba in my system. The hba
is properly connecting
Quoted 1 line
to a Target, and I can tell it seems all the LUNs
exported to it.
Quoted 1 line
However, when I browse through the
/sys/class/scsi_host/...Quoted 1 line
directory , and output of "lsscsi", I can see "sd"
mappings that are
Quoted 1 line
old and invalid (cannot write to them). In my
ouput below,
Quoted 3 lines
sd[e/f/g/h] and sd[c/d] are invalid.
1. Is there an command I an issue to flush out the
older mappings?
Quoted 5 lines
2. Is this a bug in the FC driver?
[root@pe850 ~]# lsscsi
[2:0:0:10] disk 3PARdataVV
0000/dev/sdeQuoted 1 line
[2:0:0:11] disk 3PARdata
VV
0000/dev/sdfQuoted 1 line
[2:0:0:254] enclosu 3PARdata SES
0000 -
Quoted 1 line
[2:0:1:10] disk 3PARdata
VV
0000/dev/sdgQuoted 1 line
[2:0:1:11] disk 3PARdata
VV
0000/dev/sdhQuoted 1 line
[2:0:1:254] enclosu 3PARdata SES
0000 -
Quoted 1 line
[2:0:2:10] disk 3PARdata
VV
0000/dev/sdiQuoted 1 line
[2:0:2:11] disk 3PARdata
VV
0000/dev/sdjQuoted 1 line
[2:0:2:254] enclosu 3PARdata SES
0000 -
Quoted 1 line
[3:0:0:10] disk 3PARdata
VV
0000/dev/sdcQuoted 1 line
[3:0:0:11] disk 3PARdata
VV
0000/dev/sddQuoted 1 line
[3:0:0:254] enclosu 3PARdata SES
0000 -
Quoted 1 line
[3:0:1:10] disk 3PARdata
VV
0000/dev/sdkQuoted 1 line
[3:0:1:11] disk 3PARdata
VV
0000/dev/sdlQuoted 1 line
[3:0:1:254] enclosu 3PARdata SES
0000 -
Quoted 1 line
[root@pe850 ~]#
It's very hard to tell anything without knowing which fibre HBA or
looking in the logs. However, I'd say you've had some disconnect event
which exceeded the devloss timeout twice on HBA 2 and once on HBA 1 ...
this causes LUNs to be re-presented in exactly this fashion (with the
target number incrementing).
Quoted 8 lines
It sounds like the problem is whatever event caused this, and there's
insufficient information to make any guesses about that.James
Hi James,
Thank you for your reply. It is an Emulex 2 port FC hba (LPE11002), using the inbox driver version 8.2.0.33.3p. Yes, there have been some disconnect, initiatied by me by disabling / enablling the port on the target. Even in these situations, wouldn't the driver remove the old/stale mappings? I am guessing from you response, there is no way for me to clean-up the old ones.
As to figure out which ones are real, just use the sd mapping with the latest target number, right?
Thank you,
Ahmed.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
James Bottomley
maintainerQuoted 97 lines · Ahmed A
Quoted 84 lines · James Bottomley
From: James Bottomley <[email protected]>
Subject: Re: Stale devices in sysfs
To: "Ahmed A" <[email protected]>
Cc: [email protected]
Date: Thursday, March 26, 2009, 10:41 AMQuoted 3 lines · Ahmed A
Hello,
I have a two port FC hba in my system. The hba
is properly connecting
Quoted 1 line
to a Target, and I can tell it seems all the LUNs
exported to it.
Quoted 1 line
However, when I browse through the
/sys/class/scsi_host/...Quoted 1 line
directory , and output of "lsscsi", I can see "sd"
mappings that are
Quoted 1 line
old and invalid (cannot write to them). In my
ouput below,
Quoted 3 lines
sd[e/f/g/h] and sd[c/d] are invalid.
1. Is there an command I an issue to flush out the
older mappings?
Quoted 5 lines
2. Is this a bug in the FC driver?
[root@pe850 ~]# lsscsi
[2:0:0:10] disk 3PARdataVV
0000/dev/sdeQuoted 1 line
[2:0:0:11] disk 3PARdata
VV
0000/dev/sdfQuoted 1 line
[2:0:0:254] enclosu 3PARdata SES
0000 -Quoted 1 line
[2:0:1:10] disk 3PARdata
VV
0000/dev/sdgQuoted 1 line
[2:0:1:11] disk 3PARdata
VV
0000/dev/sdhQuoted 1 line
[2:0:1:254] enclosu 3PARdata SES
0000 -Quoted 1 line
[2:0:2:10] disk 3PARdata
VV
0000/dev/sdiQuoted 1 line
[2:0:2:11] disk 3PARdata
VV
0000/dev/sdjQuoted 1 line
[2:0:2:254] enclosu 3PARdata SES
0000 -Quoted 1 line
[3:0:0:10] disk 3PARdata
VV
0000/dev/sdcQuoted 1 line
[3:0:0:11] disk 3PARdata
VV
0000/dev/sddQuoted 1 line
[3:0:0:254] enclosu 3PARdata SES
0000 -Quoted 1 line
[3:0:1:10] disk 3PARdata
VV
0000/dev/sdkQuoted 1 line
[3:0:1:11] disk 3PARdata
VV
0000/dev/sdlQuoted 1 line
[3:0:1:254] enclosu 3PARdata SES
0000 -Quoted 1 line
[root@pe850 ~]#
It's very hard to tell anything without knowing which fibre HBA or
looking in the logs. However, I'd say you've had some disconnect event
which exceeded the devloss timeout twice on HBA 2 and once on HBA 1 ...
this causes LUNs to be re-presented in exactly this fashion (with the
target number incrementing).Quoted 8 lines
It sounds like the problem is whatever event caused this, and there's
insufficient information to make any guesses about that.James
Quoted 8 lines
Hi James,
Thank you for your reply. It is an Emulex 2 port FC hba (LPE11002), using the inbox driver version 8.2.0.33.3p. Yes, there have been some disconnect, initiatied by me by disabling / enablling the port on the target. Even in these situations, wouldn't the driver remove the old/stale mappings? I am guessing from you response, there is no way for me to clean-up the old ones.
The delete caused by rport removal is supposed to remove them. There should be a message in the logs, something like :
blocked FC remote port time out: removing target and saving binding
You can delete any of the devices by just doing
echo 1 > /sys/class/scsi_device/<h:c:t:l>/device/delete
Quoted 2 lines
As to figure out which ones are real, just use the sd mapping with the latest target number, right?
Yes, the transport class allocates them from a per host incrementing variable.
James
Quoted 8 lines · James Bottomley
Quoted 6 lines
Thank you for your reply. It is an Emulex 2 port FC hba (LPE11002), using the inbox driver version 8.2.0.33.3p. Yes, there have been some disconnect, initiatied by me by disabling / enablling the port on the target. Even in these situations, wouldn't the driver remove the old/stale mappings? I am guessing from you response, there is no way for me to clean-up the old ones.
The delete caused by rport removal is supposed to remove them.
This is true of upstream. But the hint is "inbox driver". The distros added a tweak to the transport to allow an enable/disable teardown on removal, with default to teardown-disabled. This was to work around issues with sdev reallocation, which Hannes has been working on for a while due to all its nuances, where the distro isn't quite in sync with what's upstream.
Quoted 8 lines
There
should be a message in the logs, something like :blocked FC remote port time out: removing target and saving binding
You can delete any of the devices by just doing
echo 1 > /sys/class/scsi_device/<h:c:t:l>/device/delete
This will always work. Additionally, you can change the distro transport option by loading the fc transport with the module option "remove_on_dev_loss=1".
-- james s
Quoted 16 lines
Quoted 4 lines
As to figure out which ones are real, just use the sd mapping with the latest target number, right?
Yes, the transport class allocates them from a per host incrementing variable.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html