All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Reed <mdr@sgi.com>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: James.Smart@Emulex.Com, Jeremy Higdon <jeremy@sgi.com>,
	Gary Hagensen <gwh@sgi.com>,
	linux-scsi <linux-scsi@vger.kernel.org>, Jim Nead <jnead@sgi.com>,
	James Bottomley <James.Bottomley@SteelEye.com>
Subject: Re: fc transport creates second set of targets for devices in an "md"
Date: Fri, 09 Jun 2006 11:35:24 -0500	[thread overview]
Message-ID: <4489A34C.8040007@sgi.com> (raw)
In-Reply-To: <4488864E.2000009@cs.wisc.edu>



Mike Christie wrote:
> Michael Reed wrote:
>> I created an md device on two fibre channel disks, sde and sdf.
>> I then disabled the switch port to which the hba is connected.
>> After the remote port time out messages, I re-enabled the switch
>> port.  Three things happen that are weird.  First, two unexpected
>> responses while scanning.  Second, the creation of sdm and
>> sdn.  Third, the md device remains inaccessible.
>>
>> I don't think this is working the way it's intended to.  I
>> suspect it will cause big problems for multi-path volume managers
>> in a fail back situation.
>>
> 
> Even if the rport is removed and the devices under it are removed, md
> can still have a reference to the device so the memory does not
> disappear on it (MD still thinks the device is there but scsi says it is
> gone basically). Because of this, when you plug in the cable again and a
> new rport is created sd.c can end up allocating another sdX value.
> 

So, how about a callback to the driver, md, with the reference so that it
can release said reference?

Mike

  reply	other threads:[~2006-06-09 16:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-08 19:13 fc transport creates second set of targets for devices in an "md" Michael Reed
2006-06-08 19:57 ` James Smart
2006-06-09 16:26   ` Michael Reed
2006-06-09 18:10     ` Michael Reed
2006-06-09 18:22       ` Michael Reed
2006-06-08 20:19 ` Mike Christie
2006-06-09 16:35   ` Michael Reed [this message]
2006-06-09 19:34     ` Mike Christie
2006-06-09 19:52     ` James Smart
2006-06-09  0:43 ` James Bottomley
2006-06-09 16:35   ` Michael Reed
2006-06-09 19:23     ` James Bottomley

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=4489A34C.8040007@sgi.com \
    --to=mdr@sgi.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=James.Smart@Emulex.Com \
    --cc=gwh@sgi.com \
    --cc=jeremy@sgi.com \
    --cc=jnead@sgi.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.