All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Chris Lalancette <clalance@redhat.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: Greater than 16 xvd devices for blkfront
Date: Tue, 6 May 2008 18:45:51 +0100	[thread overview]
Message-ID: <20080506174551.GA12858@redhat.com> (raw)
In-Reply-To: <48209705.4030005@redhat.com>

On Tue, May 06, 2008 at 01:36:05PM -0400, Chris Lalancette wrote:
> All,
>      We've had a number of requests to increase the number of xvd devices that a
> PV guest can have.  Currently, if you try to connect > 16 disks, you get an
> error from xend.  The problem ends up being that both xend and blkfront assume
> that for dev_t, major/minor is 8 bits each, where in fact there are actually 10
> bits for major and 22 bits for minor.
>      Therefore, it shouldn't really be a problem giving lots of disks to guests.
>  The problem is in backwards compatibility, and the details.  What I am
> initially proposing to do is to leave things where they are for /dev/xvd[a-p];
> that is, still put the xenstore entries in the same place, and use 8 bits for
> the major and 8 bits for the minor.  For anything above that, we would end up
> putting the xenstore entry in a different place, and pushing the major into the
> top 10 bits (leaving the bottom 22 bits for the minor); that way old guests
> won't fire when the entry is added, and we will add code to newer guests
> blkfront so that they will fire when they see that entry.  Does anyone see any
> problems with this setup, or have any ideas how to do it better?

Putting the xenstore entries in a different place is a non-starter. Too
many things look at that location already. When blktap was added and it
put xenstore entries in a different place it took months to track down 
all the bugs this caused.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

  reply	other threads:[~2008-05-06 17:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-06 17:36 Greater than 16 xvd devices for blkfront Chris Lalancette
2008-05-06 17:45 ` Daniel P. Berrange [this message]
2008-05-07 16:04   ` Chris Wright
2008-05-07  1:55 ` Daniel P. Berrange
2008-05-07  3:47   ` Daniel P. Berrange
2008-05-07 16:40     ` Chris Wright
2008-05-08  9:30       ` Ian Jackson
2008-05-08 15:33         ` Chris Wright
2008-05-08 17:03           ` Ian Jackson
2010-02-03 16:50             ` Xen vbd numbering Ian Jackson
2008-05-08 22:14           ` Greater than 16 xvd devices for blkfront Jeremy Fitzhardinge
2008-05-08 23:34             ` Daniel P. Berrange

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=20080506174551.GA12858@redhat.com \
    --to=berrange@redhat.com \
    --cc=clalance@redhat.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.