|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Blkfront support for get geometry ioctl
>
> > 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
|
|