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
next prev parent 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.