Hi,
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!).
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):
---
xeno-unstable-pristine/linux-2.6.8.1-xen-sparse/drivers/xen/blkfront/blkfront.c
Wed Sep 1 10:45:33 2004
+++
xeno-unstable.bk/linux-2.6.8.1-xen-sparse/drivers/xen/blkfront/blkfront.c
Wed Sep 1 10:46:27 2004
@@ -510,6 +510,8 @@
struct gendisk *gd;
struct hd_struct *part;
int i;
+ unsigned short cylinders;
+ byte heads, sectors;
/* NB. No need to check permissions. That is done for us. */
@@ -554,23 +556,39 @@
break;
case HDIO_GETGEO:
- /* note: these values are complete garbage */
DPRINTK_IOCTL(" HDIO_GETGEO: %x\n", HDIO_GETGEO);
if (!argument) return -EINVAL;
+
+ /* We don''t have real geometry info, but let''s at
least return
+ values consistent with the size of the device */
+
+ heads = 0xff;
+ sectors = 0x3f;
+ cylinders = part->nr_sects / (heads * sectors);
+
if (put_user(0x00, (unsigned long *) &geo->start)) return
-EFAULT;
- if (put_user(0xff, (byte *)&geo->heads)) return -EFAULT;
- if (put_user(0x3f, (byte *)&geo->sectors)) return -EFAULT;
- if (put_user(0x106, (unsigned short *)&geo->cylinders)) return
-EFAULT;
+ if (put_user(heads, (byte *)&geo->heads)) return -EFAULT;
+ if (put_user(sectors, (byte *)&geo->sectors)) return -EFAULT;
+ if (put_user(cylinders, (unsigned short *)&geo->cylinders))
return
-EFAULT;
+
return 0;
case HDIO_GETGEO_BIG:
- /* note: these values are complete garbage */
DPRINTK_IOCTL(" HDIO_GETGEO_BIG: %x\n", HDIO_GETGEO_BIG);
if (!argument) return -EINVAL;
+
+ /* We don''t have real geometry info, but let''s at
least return
+ values consistent with the size of the device */
+
+ heads = 0xff;
+ sectors = 0x3f;
+ cylinders = part->nr_sects / (heads * sectors);
+
if (put_user(0x00, (unsigned long *) &geo->start)) return
-EFAULT;
- if (put_user(0xff, (byte *)&geo->heads)) return -EFAULT;
- if (put_user(0x3f, (byte *)&geo->sectors)) return -EFAULT;
- if (put_user(0x106, (unsigned int *) &geo->cylinders)) return
-EFAULT;
+ if (put_user(heads, (byte *)&geo->heads)) return -EFAULT;
+ if (put_user(sectors, (byte *)&geo->sectors)) return -EFAULT;
+ if (put_user(cylinders, (unsigned int *) &geo->cylinders))
return
-EFAULT;
+
return 0;
case CDROMMULTISESSION:
--
Dr. Stephen Childs,
Research Fellow, EGEE Project, phone: +353-1-6081720
Computer Architecture Group, email: Stephen.Childs @ cs.tcd.ie
Trinity College Dublin, Ireland web: http://www.cs.tcd.ie/Stephen.Childs
-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > 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...Probably not worth it -- any sane program ought to be using BLKGETSIZE or BLKGETSIZE64. I think a simple "good enough" estimate will do for GETGEO. At the same time as checking in that patch, we should also investigate why 2.6 has a completely different ioctl implementation that doesn''t actually do anything! Merging the two ioctl functions would seem a good idea. -- Keir ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Christian Limpach
2004-Sep-01 21:48 UTC
Re: [Xen-devel] Blkfront support for get geometry ioctl
On Wed, Sep 01, 2004 at 02:50:14PM +0100, Keir Fraser wrote:> why 2.6 has a completely different ioctl implementation that doesn''t > actually do anything! Merging the two ioctl functions would seem a > good idea.Most of those ioctl''s would seem to be handled by generic code. I''m somewhat surprised that it''s not the case for the GEOM one, I thought it was. christian ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> On Wed, Sep 01, 2004 at 02:50:14PM +0100, Keir Fraser wrote: > > why 2.6 has a completely different ioctl implementation that doesn''t > > actually do anything! Merging the two ioctl functions would seem a > > good idea. > > Most of those ioctl''s would seem to be handled by generic code. I''m > somewhat surprised that it''s not the case for the GEOM one, I thought > it was.On 2.6 it might be. Stephen''s patch is for the 2.4 ioctl. -- Keir ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > > 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.Stephen, It''s worth having a look at the following patch to add whole disk partition table support to the loop back device: ftp://ftp.hq.nasa.gov/pub/ig/ccd/enhanced_loopback/patches/enhanced_loop-2.4.20.patch They seem to initialise the geometry information to all zeros, and simply return all zeros, unless someone uses HDIO_SETGEO to set it to something else. I wander if a similar strategy could work for you, rather than inventing a bogus geometry? Would you mind trying this out? It might be worth strace''ing fdisk to see if it uses HDIO_SETGEO to configure a geometry if it gets all zeros back from GETGEO. Thanks, 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel