All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Kamada <kama@jp.fujitsu.com>
To: Steven Smith <steven.smith@eu.citrix.com>
Cc: kama@jp.fujitsu.com, xen-devel@lists.xensource.com
Subject: Re: [Patch 0/7] pvSCSI driver
Date: Tue, 04 Mar 2008 16:57:43 +0900	[thread overview]
Message-ID: <20080304161920.AAEC.EB2C8575@jp.fujitsu.com> (raw)
In-Reply-To: <20080303113857.GA15396@weybridge.uk.xensource.com>

Hi Steven-san,

On Mon, 3 Mar 2008 11:38:57 +0000
Steven Smith <steven.smith@eu.citrix.com> wrote:

> > > What I don't understand is why you need this at all.  It seems like it
> > > would make more sense to either:
> > > 
> > > a) Hang every LUN off of the same scsi host, or
> > > b) Give each LUN its own scsi host.
> > > 
> > > Is there some reason why you might want to do something like this:
> > > 
> > > Host A  -------+----- LUN 1
> > >                |
> > >                +----- LUN 2
> > > 
> > > Host B  ------------- LUN 3
> > > 
> > > i.e. partition the virtual LUNs between multiple hosts in the guest,
> > > but keeping some of them together?  Perhaps I'm just missing
> > > something, but I can't think of any use cases which would benefit from
> > > that, and trying to support it noticeably complicates the frontend.
> > Can I explain a numbering logic of assigning LUNs to guests?
> That was what I was hoping you'd do, yes. :)
> 
> > Basically, each guest looks same SCSI tree as host except for following
> > two points. 
> > 
> > 1.) The "host" in 4-tuples "host:channel:id:lun" on guest may not be
> >     same as that on host. 
> > 2.) Tree on the guest may be sparse when some LUN doesn't assign to
> >     the guest.
> > 
> > Therefore, "a1:b:c:d" on host becomes "a2:b:c:d" on guest. (a1 != a2
> > generally)
> Okay, why do you require that the device in the guest has the same
> channel:id:lun as the device on the host?  That seems like a somewhat
> gratuitous restriction to me.
> 
> > I think the numbering logic is same as b) you mentioned above. Is it
> > right?
> No, you've gone for option c:
> 
> c) The topology inside the guest reflects a subset of the host
>    topology
> 
> which I hadn't previously considered.

The reason why we took the option c is as follows.

- Some storage management software running on guest may asume physical
  topology. (However, I'm not sure whether there is such a software or
  not.)
- The "host" is Linux specific number and Scsi-Host structure for
  dummy consumes relatively large memory space. Therefore, we decided
  to compress the "host" number. (Not sparse. Contiguous.)


Explicit declaration like below may be one solution. Of cource some
default setting is needed.


On Dom0        On Guest
------------------------
"1:2:3:4" ---> "5:6:7:8"


Best regards,


Jun Kamada

  reply	other threads:[~2008-03-04  7:57 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-18 10:10 [Patch 0/7] pvSCSI driver Jun Kamada
2008-02-18 12:14 ` James Harper
2008-02-19  2:26   ` Jun Kamada
2008-02-19  2:28     ` James Harper
2008-02-20  3:58 ` James Harper
2008-02-20  5:09   ` Jun Kamada
2008-02-21  2:19 ` James Harper
2008-02-21  3:39   ` James Harper
2008-02-21  4:23     ` Jun Kamada
2008-02-21  5:30       ` James Harper
2008-02-25  1:53         ` Jun Kamada
2008-02-27 11:16 ` Steven Smith
2008-02-28  2:51   ` Jun Kamada
2008-02-28 11:13     ` Steven Smith
2008-02-29  4:47       ` Jun Kamada
2008-03-03 11:38         ` Steven Smith
2008-03-04  7:57           ` Jun Kamada [this message]
2008-03-04 13:05             ` Steven Smith
2008-03-05  2:34               ` James Harper
2008-03-05  9:53                 ` Jun Kamada
2008-03-05  9:56                   ` James Harper
2008-03-05 10:00                     ` Jun Kamada
2008-03-06 23:48                       ` Dan Magenheimer
2008-03-07  1:20                         ` Jun Kamada
2008-03-07  2:55                 ` Jun Kamada
2008-03-07  4:31                   ` James Harper
2008-03-14 19:04                     ` James Smart
2008-03-10 12:00                   ` Steven Smith
2008-03-12  6:23                     ` Jun Kamada
2008-03-13 14:30                       ` Steven Smith
2008-03-17  2:33                         ` Jun Kamada
2008-03-17 17:29                           ` Steven Smith
2008-03-14 19:16                       ` James Smart
2008-03-17  2:59                         ` Jun Kamada

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=20080304161920.AAEC.EB2C8575@jp.fujitsu.com \
    --to=kama@jp.fujitsu.com \
    --cc=steven.smith@eu.citrix.com \
    --cc=xen-devel@lists.xensource.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.