public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Smart <James.Smart@Emulex.Com>
To: Michael Reed <mdr@sgi.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>,
	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 15:52:57 -0400	[thread overview]
Message-ID: <4489D199.5020609@emulex.com> (raw)
In-Reply-To: <4489A34C.8040007@sgi.com>

Michael Reed wrote:
>> 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 C summarized the issue well. Callback - ugh. The real wish-list fix is to
make the midlayer reuse the old structures if the device comes back. Makes my
eyes bug out though to figure out this could be done. This would also solve
the race we saw in sysfs for recreation of the node while it was still outstanding
due to a reference (name collision).

-- james


  parent reply	other threads:[~2006-06-09 19:53 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
2006-06-09 19:34     ` Mike Christie
2006-06-09 19:52     ` James Smart [this message]
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=4489D199.5020609@emulex.com \
    --to=james.smart@emulex.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=gwh@sgi.com \
    --cc=jeremy@sgi.com \
    --cc=jnead@sgi.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mdr@sgi.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox