[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Support for official xvd major number



Hi,

Rumor has it that on Thu, Jul 14, 2005 at 05:57:58PM -0400 Jeremy Katz said:
> On Thu, 2005-07-14 at 22:38 +0100, Keir Fraser wrote:
> > On 14 Jul 2005, at 22:35, Jeremy Katz wrote:
> > > Also, on a side note that is really unrelated to the patch, is there
> > > really a good reason why these hoops are still gone through instead of
> > > having the kernel allocate the next disk instead of the hard-coding 
> > > with
> > > things somewhat out of order and stealing the major/minors of other
> > > subsystems?
> > 
> > I'm not sure what you mean? Specifying device numbers up front in a 
> > config file means that you know e.g., what device names to put in your 
> > fstab and what to specify as your rootfs device. 
> 
> Your first disk should get registered first and be xvda, your second
> xvdb, etc.  If you're afraid of the order changing, you should be using
> label or uuid to mount.  The same questions come up with physical
> devices.

In a virtualized world where your block device can be moved from
system to system in software using labels is unwise. When your 
disk is internal it's not really a problem, but when you move disks 
around easily the labels get in the way. Duplicate "/" will keep your 
system from booting. The label thing is basically a hack to get around 
the brain dead device naming in linux. The hda/hdb/hdc thing only
makes sense for internal IDE disks and even then you have issues now
that sata shows up the same way. It's too bad the original linux scsi
implementation followed this model.

There's no reason to enforce that first-in ordering for xvd devices
that I can see. Specify where you want the device to show up and then
access it there. 

Physical devices do have the same issues, but those are really solved 
by using udev (and helpers like scsi_id) not fs labels and uuids. Besides, 
labels are only useful if you have a filesystem on that block device. 
Not all block devices have file systems...


Cheers,

Phil

-- 
Philip R. Auld, Ph.D.                          Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.