public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Linton <jlinton@tributary.com>
To: Hannes Reinecke <hare@suse.de>,
	James Bottomley <jbottomley@parallels.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Doug Gilbert <dgilbert@interlog.com>,
	Kai Makisara <kai.makisara@kolumbus.fi>,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCHv2] Add EVPD page 0x83 entries to sysfs
Date: Tue, 11 Feb 2014 10:56:38 -0600	[thread overview]
Message-ID: <52FA5646.4070009@tributary.com> (raw)
In-Reply-To: <52F9E00B.7070707@suse.de>

On 2/11/2014 2:32 AM, Hannes Reinecke wrote:
> The problem with page 0x80 is that (per spec) it's vendor-defined. So there
> is no guarantee for it to be unique in any sense. Which makes it rather
> impractical for normal use.
> 
> Hence we typically rely on page 0x83 to identify a device, be it for udev
> or multipath.

	AFAIK is not vendor defined page, its just not marked as "mandatory" by T10.
For tape (which I what I thought brought much of this on) it is basically
mandatory. Which is another place where the spec doesn't sync with the real
world.

	That is because it is the _ONLY_ vendor neutral method to autoconfigure tape
libraries. The tape libraries export the drive serial numbers via READ ELEMENT
STATUS, dvcid=1. Which means its the de facto method for backup/media manager
applications. A tape/media changer device that crashes or fails to return useful
0x80 information will have a very short life in the market.

	For sure, it would work better than the existing method being used by udev (for
tape), which fails (per my other posting) because there is often insufficient
information in 0x83 to uniquely identify devices.




	

      reply	other threads:[~2014-02-11 16:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 11:11 [PATCHv2] Add EVPD page 0x83 entries to sysfs Hannes Reinecke
2014-02-10 14:15 ` Christoph Hellwig
2014-02-10 14:55   ` Hannes Reinecke
2014-02-10 18:06 ` Jeremy Linton
2014-02-10 19:06   ` Douglas Gilbert
2014-02-11 10:52     ` Hannes Reinecke
2014-02-11  8:32   ` Hannes Reinecke
2014-02-11 16:56     ` Jeremy Linton [this message]

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=52FA5646.4070009@tributary.com \
    --to=jlinton@tributary.com \
    --cc=dgilbert@interlog.com \
    --cc=hare@suse.de \
    --cc=jbottomley@parallels.com \
    --cc=kai.makisara@kolumbus.fi \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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