From: Michael Reed <mdr@sgi.com>
To: Steve Byan <smb@egenera.com>
Cc: James.Smart@Emulex.Com, Christoph Hellwig <hch@infradead.org>,
linux-scsi <linux-scsi@vger.kernel.org>, Jim Nead <jnead@sgi.com>,
Jeremy Higdon <jeremy@sgi.com>, Gary Hagensen <gwh@sgi.com>
Subject: Re: [PATCH] make fc transport removal of target configurable
Date: Tue, 13 Jun 2006 14:35:39 -0500 [thread overview]
Message-ID: <448F138B.2020109@sgi.com> (raw)
In-Reply-To: <7A809A3B-B514-4ADE-A717-595250103E56@egenera.com>
Steve Byan wrote:
> On Jun 13, 2006, at 11:42 AM, Michael Reed wrote:
>
>> Treating fibre channel like removable storage is wrong. Fibre
>> targets aren't
>> generally supposed to go away. If they do, there's a significant
>> chance
>> that they'll be repaired and returned to service. It makes sense
>> to keep
>> the infrastructure in place just like scsi, sas, iscsi, ata.
>
> In both Fibre Channel SANs and iSCSI SANs, administrators in large
> datacenters will re-zone devices with some regularity as they
> redeploy applications among existing systems.
Yes, they will. And don't they generally do this gracefully, i.e,
shut down access to file systems or devices before rezoning? And when
the target is rezoned to the host again don't they expect to be able
to resume using it. This patch allows that to happen with no
user intervention.
>
>> The kind of disruption the current code can cause to systems with
>> multi-terabytes
>> or petabytes of storage will be considered unacceptable in a
>> production environment.
>
> Agreed; but Fibre Channel and SAN devices _will_ come and go
> dynamically.
My concern is when targets go in an uncontrolled manner.
>
>> So, I also wish to encourage a reconsideration of the position that
>> dead targets
>> should be removed. Removing removable storage targets like
>> firewire and usb
>> makes sense. I just don't believe that the same applies to fibre
>> channel
>> or other generally non-removable targets.
>
> Think of removing a Fibre Channel or iSCSI device as "removing access
> authorization". You're correct that these devices are not often
> physically removed from the SAN, but access authorization may change
> frequently.
When the target "self-removes" and "self-attaches" I want the existing
user of the target to be able to resume use. By not removing the
infrastructure in these situations less disruption to a production
system occurs. The existing "user" has to be tolerant of errors during
this period of absence if it wishs to resume use.
This patch allows that to happen if the admin so desires.
Mike
>
> Regards,
> -Steve
next prev parent reply other threads:[~2006-06-13 19:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-12 23:16 [PATCH] make fc transport removal of target configurable Michael Reed
2006-06-13 7:07 ` Christoph Hellwig
2006-06-13 11:06 ` James Smart
2006-06-13 15:42 ` Michael Reed
2006-06-13 17:24 ` Stefan Richter
2006-06-13 19:36 ` Michael Reed
2006-06-13 23:13 ` Stefan Richter
2006-06-13 17:33 ` Steve Byan
2006-06-13 19:35 ` Michael Reed [this message]
2006-06-13 19:49 ` Steve Byan
2006-06-13 17:59 ` James Bottomley
2006-06-13 19:37 ` Michael Reed
2006-06-13 20:02 ` James Bottomley
2006-06-13 21:44 ` Michael Reed
2006-06-14 7:21 ` Hannes Reinecke
2006-06-14 16:18 ` Mike Christie
2006-06-14 16:31 ` Mike Christie
2006-06-15 9:04 ` Stefan Richter
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=448F138B.2020109@sgi.com \
--to=mdr@sgi.com \
--cc=James.Smart@Emulex.Com \
--cc=gwh@sgi.com \
--cc=hch@infradead.org \
--cc=jeremy@sgi.com \
--cc=jnead@sgi.com \
--cc=linux-scsi@vger.kernel.org \
--cc=smb@egenera.com \
/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