WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Blkfront support for get geometry ioctl

To: Stephen Childs <Stephen.Childs@xxxxxxxxx>
Subject: Re: [Xen-devel] Blkfront support for get geometry ioctl
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Wed, 01 Sep 2004 13:16:26 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Wed, 01 Sep 2004 13:31:10 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Wed, 01 Sep 2004 11:54:24 BST." <4135AA60.100@xxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> Continuing my battle with LCFGng installation onto Xen, I was puzzled by the 
> fact that whatever size drive I exported to Xen, the partitioning program 
> always seemed to think the disk size was approx 2.1 GB. After some probing, 
> I realised that the program LCFG uses to determine disk size (based on 
> RedHat's libfdisk I think) does so by performing an ioctl to get the 
> geometry of the disk. The code in blkfront "implements" the HDIO_GETGEO 
> ioctl by returning garbage results for cyls, heads, and sectors/track. (the 
> figures in question: 63*255*262 -- equals approx 2.1 GB!).

As you've discovered, exporting a device to a whole disk target
hasn't been widely tested -- most people export devices to
partitions.
 
> Do you think it would be possible to return geometry values that are at 
> least consistent with the size of the device? Something like this (still has 
> hard-coded heads and sectors, but calculates cyls based on size of disk):

It certainly seems sensible to return geometry that approximates
the "disk's" total size. Your current patch can 'waste' up to 8MB
of disk space. Do you think it's worth doing something iterative
that plays around with different numbers of heads and sectors to
find a total <= disk size?

I'll bet there's some stock code we could use to do this...

Ian


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel