From: Brian Waite <waite@skycomputers.com>
To: Patrick Mansfield <patmans@us.ibm.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [RFC] [PATCH] 0/7 2.5.35 SCSI multi-path
Date: Wed, 18 Sep 2002 11:17:59 -0400 [thread overview]
Message-ID: <200209181117.59388.waite@skycomputers.com> (raw)
In-Reply-To: <20020917154940.A18401@eng2.beaverton.ibm.com>
On Tuesday 17 September 2002 6:49 pm, Patrick Mansfield wrote:
>
> Currently, multi-path support requires a SCSI device that supports one of
> the SCSI INQUIRY device identification pages (page 0x80 or 0x83). Devices
> not supporting one of these pages are treated as if they were separate
> devices. Devices that do not give a unique serial number per LUN for these
> commands might incorrectly be identified as multi-pathed.
>
I might be wrong about this, I have put most of this out of my mind, but I
belive that many tape drives and many cdrom drives do not return a serial
number. Does this mean two seperate tape drives will "appear" as a single
multi-port device, and worse could a cdrom and a tape device appear as the
same device or do you seperate between device types and then serial numbers.\
I was working on exactly this problem in Linux a while ago and we were
running into serial number as uniqueness problems. What we chose to do was
create a "uniqueness" driver that would first use a customer derived
uniquness mecanism, IE "host:bus:channel:device is a single ported device of
type XXX". The fall though mechanism was to query the serial number and if it
was zero, or provided no serial number, then it could not be a multiported
device. Of course for most scsi disks, the serial number was adequate to
provide multiported-ness.
PS. There is nothing funnier than putting 2 tape drives on a system that
decides it is a single multiported device, starting a tar, and pulling the
drive it was writing to, only to watch the tar continue merrily ontl the
second tape drive. Sure you get your backup, the restore is a real bugger tho
:)
Sorry to waste bandwidth if you've already discussed, I am probably a bit late
to the discussion.
Thanks
Brian
next prev parent reply other threads:[~2002-09-18 15:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-17 22:49 [RFC] [PATCH] 0/7 2.5.35 SCSI multi-path Patrick Mansfield
2002-09-17 22:50 ` [RFC] [PATCH] 1/7 " Patrick Mansfield
2002-09-17 22:50 ` [RFC] [PATCH] 2/7 " Patrick Mansfield
2002-09-17 22:51 ` [RFC] [PATCH] 3/7 " Patrick Mansfield
2002-09-17 22:52 ` [RFC] [PATCH] 4/7 " Patrick Mansfield
2002-09-17 22:52 ` [RFC] [PATCH] 5/7 " Patrick Mansfield
2002-09-17 22:53 ` [RFC] [PATCH] 6/7 " Patrick Mansfield
2002-09-17 22:54 ` [RFC] [PATCH] 7/7 " Patrick Mansfield
2002-09-18 15:17 ` Brian Waite [this message]
2002-09-18 16:08 ` [RFC] [PATCH] 0/7 " Patrick Mansfield
2002-09-19 21:16 ` Bill Davidsen
2002-09-19 21:29 ` Brian Waite
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=200209181117.59388.waite@skycomputers.com \
--to=waite@skycomputers.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=patmans@us.ibm.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