public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christof Schmitt <christof.schmitt@de.ibm.com>
To: Mike Anderson <andmike@us.ibm.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH] zfcp: Report FCP LUN to SCSI midlayer
Date: Fri, 22 Jun 2007 13:34:40 +0200	[thread overview]
Message-ID: <20070622113439.GA6015@schmichrtp.de.ibm.com> (raw)
In-Reply-To: <20070622044035.GB5560@us.ibm.com>

On Thu, Jun 21, 2007 at 09:40:35PM -0700, Mike Anderson wrote:
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
> > A proposal to display the correct form of the LUN would be useful if you
> > wish to make it? ...  The problem is really that SAM specifies a
> > possible 4 level structure with 4 possible address methods per level.
> > 
> > The well known LUNs should be simple; there are only three: Report Lun,
> > Access Controls and Target Log Pages.  The rest we really need input on.
> > For instance, I could see the vendors wishing us to combine a
> > multi-level flat addressing space into a single logical unit number,
> > whereas I could see them wanting us to supply some sort of hierarchy for
> > the peripheral and logical unit methods of addressing.
> > 
> > Since you're already using 2 level flat addressing, how do you want to
> > see that represented?
> 
> James, why would we would not want to display the lun per SAM4 4.6.2 as
> suggested by Stefan in a previous comment.

I would also agree to display the LUN in sysfs as 64 bit hex number as
advised in SAM4.

While the SAM describes different formats and addressing schemes, i
don't see how this affects the SCSI layer in the kernel. The kernel
gets the 64 bit LUNs and uses them as unique ids. 4.6.1 in SAM4 says
in the last sentence, that different values for the 64 bits represent
different LUNs, so the assumption of the LUNs being unique is
guaranteed.

My point of view is mainly from the device driver's (zfcp) and user's
point of view. It is only that the disk systems i deal with use the 2
level addressing in the LUNs. The user interface of the disk system
displays something like: Volume F000 is exported as FCP LUN 40F04000.
When the SCSI midlayer uses and exports this value in sysfs, it should
be displayed in the same format (hex).

I don't know if the multi level scheme is actually used as hierarchy
somewhere. If somebody would be interested in using this information,
i think a userspace tool could grab the value from sysfs and display
the detailed information according to SAM.

--
Christof Schmitt

  reply	other threads:[~2007-06-22 11:35 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-19  8:25 [PATCH] zfcp: Report FCP LUN to SCSI midlayer Swen Schillig
2007-06-19  8:28 ` Hannes Reinecke
2007-06-19 12:19 ` Stefan Richter
2007-06-19 17:12 ` Christoph Hellwig
2007-06-20  2:46   ` James Bottomley
2007-06-21 15:03     ` Christof Schmitt
2007-06-21 16:46       ` Stefan Richter
2007-06-21 16:54         ` Stefan Richter
2007-06-22  1:41         ` James Bottomley
2007-06-22 19:01           ` Stefan Richter
2007-06-21 20:58       ` James Bottomley
2007-06-22  4:40         ` Mike Anderson
2007-06-22 11:34           ` Christof Schmitt [this message]
2007-06-22 14:11           ` James Bottomley
2007-06-22 16:16             ` Doug Maxey
2007-06-25 20:43               ` Luben Tuikov
2007-06-25 22:53                 ` Stefan Richter
2007-06-25 10:39             ` Swen Schillig
2007-06-25 14:03               ` Hannes Reinecke
2007-06-25 18:57                 ` Stefan Richter
2007-06-25 21:27                   ` Luben Tuikov
2007-06-25 21:55                     ` Stefan Richter
2007-06-26  0:35                       ` Luben Tuikov
2007-06-26 21:29                     ` Matthew Wilcox
2007-06-25 21:48                   ` James Bottomley
2007-06-25 22:27                     ` Stefan Richter
2007-06-26  1:04                       ` Luben Tuikov
2007-06-26 10:44                         ` Stefan Richter
2007-06-26 14:20                           ` James Bottomley
2007-06-26 15:47                             ` Stefan Richter
2007-06-26 17:01                               ` James Bottomley
2007-06-27  0:27                                 ` Stefan Richter
2007-06-27  0:45                                 ` [PATCH] SCSI: delete outdated comment in API reference Stefan Richter
2007-06-26  0:49                     ` [PATCH] zfcp: Report FCP LUN to SCSI midlayer Luben Tuikov
2007-06-26  9:38                       ` Stefan Richter
2007-06-27 10:27                 ` Swen Schillig
2007-06-28  4:21                   ` Luben Tuikov
2007-06-28 15:40                     ` Stefan Richter
2007-06-30 19:07                       ` Luben Tuikov
2007-06-30 21:26                         ` Stefan Richter
2007-07-01  6:27                           ` Luben Tuikov
2007-07-01 11:07                             ` Stefan Richter
2007-06-25 20:32             ` Luben Tuikov

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=20070622113439.GA6015@schmichrtp.de.ibm.com \
    --to=christof.schmitt@de.ibm.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=andmike@us.ibm.com \
    --cc=linux-scsi@vger.kernel.org \
    /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