public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ahmed A <ahmedcali@yahoo.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: Stale devices in sysfs
Date: Thu, 26 Mar 2009 17:41:38 +0000	[thread overview]
Message-ID: <1238089298.3342.39.camel@localhost.localdomain> (raw)
In-Reply-To: <566532.22288.qm@web32501.mail.mud.yahoo.com>

On Thu, 2009-03-26 at 10:16 -0700, Ahmed A wrote:
> Hello,
> 
> I have a two port FC hba in my system.  The hba is properly connecting
> to a Target, and I can tell it seems all the LUNs exported to it.
> However, when I browse through the /sys/class/scsi_host/...
> directory , and output of "lsscsi", I can see "sd" mappings that are
> old and invalid (cannot write to them).  In my ouput below,
> 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?
> 
> 2. Is this a bug in the FC driver?
> 
> [root@pe850 ~]# lsscsi
> [2:0:0:10]   disk    3PARdata VV               0000  /dev/sde
> [2:0:0:11]   disk    3PARdata VV               0000  /dev/sdf
> [2:0:0:254]  enclosu 3PARdata SES              0000  -       
> [2:0:1:10]   disk    3PARdata VV               0000  /dev/sdg
> [2:0:1:11]   disk    3PARdata VV               0000  /dev/sdh
> [2:0:1:254]  enclosu 3PARdata SES              0000  -       
> [2:0:2:10]   disk    3PARdata VV               0000  /dev/sdi
> [2:0:2:11]   disk    3PARdata VV               0000  /dev/sdj
> [2:0:2:254]  enclosu 3PARdata SES              0000  -       
> [3:0:0:10]   disk    3PARdata VV               0000  /dev/sdc
> [3:0:0:11]   disk    3PARdata VV               0000  /dev/sdd
> [3:0:0:254]  enclosu 3PARdata SES              0000  -       
> [3:0:1:10]   disk    3PARdata VV               0000  /dev/sdk
> [3:0:1:11]   disk    3PARdata VV               0000  /dev/sdl
> [3:0:1:254]  enclosu 3PARdata SES              0000  -       
> [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).

It sounds like the problem is whatever event caused this, and there's
insufficient information to make any guesses about that.

James



  reply	other threads:[~2009-03-26 17:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-26 17:16 Stale devices in sysfs Ahmed A
2009-03-26 17:41 ` James Bottomley [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-03-26 18:51 Ahmed A
2009-03-26 21:44 ` James Bottomley
2009-03-27 13:37   ` James Smart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1238089298.3342.39.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=ahmedcali@yahoo.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox