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: Wed, 7 May 2008 04:47:26 +0100 [thread overview]
Message-ID: <20080507034726.GC2121@redhat.com> (raw)
In-Reply-To: <20080507015502.GA2121@redhat.com>
On Wed, May 07, 2008 at 02:55:02AM +0100, Daniel P. Berrange wrote:
> 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?
>
> Looking at the blkfront code I think we can increase the minor numbers
> available for xvdX devices without requiring changes to the where stuff
> is stored.
Have a go with this proof of concept patch to blkfront. I built pv-on-hvm drivers
with this and successfully booted my guest with 25 disks (xvdb -> xvdz) and saw
them registered in /dev as can be seen from /proc/partitions:
major minor #blocks name
3 0 5242880 hda
3 1 104391 hda1
3 2 5132767 hda2
253 0 4096000 dm-0
253 1 1015808 dm-1
202 16 102400 xvdb
202 32 102400 xvdc
202 48 102400 xvdd
202 49 48163 xvdd1
202 50 48195 xvdd2
202 64 102400 xvde
202 80 102400 xvdf
202 96 102400 xvdg
202 112 102400 xvdh
202 128 102400 xvdi
202 144 102400 xvdj
202 160 102400 xvdk
202 176 102400 xvdl
202 192 102400 xvdm
202 208 102400 xvdn
202 224 102400 xvdo
202 240 102400 xvdp
202 256 102400 xvdq
202 272 102400 xvdr
202 288 102400 xvds
202 304 102400 xvdt
202 320 102400 xvdu
202 336 102400 xvdv
202 352 102400 xvdw
202 368 102400 xvdx
202 384 102400 xvdy
202 400 102400 xvdz
202 401 96358 xvdz1
NB, requires the regex tweak to blkif.py in XenD to allow xvd[a-z] naming.
Regards,
Daniel.
diff -r 57ab8dd47580 drivers/xen/blkfront/vbd.c
--- a/drivers/xen/blkfront/vbd.c Sun Jul 01 22:07:32 2007 +0100
+++ b/drivers/xen/blkfront/vbd.c Tue May 06 23:38:20 2008 -0400
@@ -166,7 +166,14 @@ xlbd_get_major_info(int vdevice)
index = 18 + major - SCSI_DISK8_MAJOR;
break;
case SCSI_CDROM_MAJOR: index = 26; break;
- default: index = 27; break;
+ default:
+ index = 27;
+ if (major > XLBD_MAJOR_VBD_START) {
+ printk("xen-vbd: fixup major/minor %d -> %d,%d\n", vdevice, major, minor);
+ minor += (16 * 16 * (major - 202));
+ major = 202;
+ }
+ printk("xen-vbd: process major/minor %d -> %d,%d\n", vdevice, major, minor);
}
mi = ((major_info[index] != NULL) ? major_info[index] :
@@ -315,14 +322,42 @@ xlvbd_add(blkif_sector_t capacity, int v
{
struct block_device *bd;
int err = 0;
+ int major, minor;
- info->dev = MKDEV(BLKIF_MAJOR(vdevice), BLKIF_MINOR(vdevice));
+ major = BLKIF_MAJOR(vdevice);
+ minor = BLKIF_MINOR(vdevice);
+
+ switch (major) {
+ case IDE0_MAJOR:
+ case IDE1_MAJOR:
+ case IDE2_MAJOR:
+ case IDE3_MAJOR:
+ case IDE4_MAJOR:
+ case IDE5_MAJOR:
+ case IDE6_MAJOR:
+ case IDE7_MAJOR:
+ case IDE8_MAJOR:
+ case IDE9_MAJOR:
+ case SCSI_DISK0_MAJOR:
+ case SCSI_DISK1_MAJOR ... SCSI_DISK7_MAJOR:
+ case SCSI_DISK8_MAJOR ... SCSI_DISK15_MAJOR:
+ case SCSI_CDROM_MAJOR:
+ break;
+
+ default:
+ if (major > 202) {
+ minor += (16 * 16 * (major - 202));
+ major = 202;
+ }
+ }
+
+ info->dev = MKDEV(major, minor);
bd = bdget(info->dev);
if (bd == NULL)
return -ENODEV;
- err = xlvbd_alloc_gendisk(BLKIF_MINOR(vdevice), capacity, vdevice,
+ err = xlvbd_alloc_gendisk(minor, capacity, vdevice,
vdisk_info, sector_size, info);
bdput(bd);
--
|: 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 :|
next prev parent reply other threads:[~2008-05-07 3:47 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
2008-05-07 16:04 ` Chris Wright
2008-05-07 1:55 ` Daniel P. Berrange
2008-05-07 3:47 ` Daniel P. Berrange [this message]
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=20080507034726.GC2121@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.