* Blkfront support for get geometry ioctl
@ 2004-09-01 10:54 Stephen Childs
2004-09-01 12:16 ` Ian Pratt
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Childs @ 2004-09-01 10:54 UTC (permalink / raw)
To: xen-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Blkfront support for get geometry ioctl
2004-09-01 10:54 Blkfront support for get geometry ioctl Stephen Childs
@ 2004-09-01 12:16 ` Ian Pratt
2004-09-01 13:50 ` Keir Fraser
2004-09-03 2:40 ` Ian Pratt
0 siblings, 2 replies; 6+ messages in thread
From: Ian Pratt @ 2004-09-01 12:16 UTC (permalink / raw)
To: Stephen Childs; +Cc: xen-devel, Ian.Pratt
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Blkfront support for get geometry ioctl
2004-09-01 12:16 ` Ian Pratt
@ 2004-09-01 13:50 ` Keir Fraser
2004-09-01 21:48 ` Christian Limpach
2004-09-03 2:40 ` Ian Pratt
1 sibling, 1 reply; 6+ messages in thread
From: Keir Fraser @ 2004-09-01 13:50 UTC (permalink / raw)
To: Ian Pratt; +Cc: Stephen Childs, 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Blkfront support for get geometry ioctl
2004-09-01 13:50 ` Keir Fraser
@ 2004-09-01 21:48 ` Christian Limpach
2004-09-01 22:03 ` Keir Fraser
0 siblings, 1 reply; 6+ messages in thread
From: Christian Limpach @ 2004-09-01 21:48 UTC (permalink / raw)
To: Keir Fraser; +Cc: Ian Pratt, Stephen Childs, 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.
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Blkfront support for get geometry ioctl
2004-09-01 21:48 ` Christian Limpach
@ 2004-09-01 22:03 ` Keir Fraser
0 siblings, 0 replies; 6+ messages in thread
From: Keir Fraser @ 2004-09-01 22:03 UTC (permalink / raw)
To: Christian Limpach; +Cc: Keir Fraser, Ian Pratt, Stephen Childs, 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Blkfront support for get geometry ioctl
2004-09-01 12:16 ` Ian Pratt
2004-09-01 13:50 ` Keir Fraser
@ 2004-09-03 2:40 ` Ian Pratt
1 sibling, 0 replies; 6+ messages in thread
From: Ian Pratt @ 2004-09-03 2:40 UTC (permalink / raw)
Cc: Stephen Childs, xen-devel, Ian.Pratt
>
> > 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-09-03 2:40 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-09-01 10:54 Blkfront support for get geometry ioctl Stephen Childs
2004-09-01 12:16 ` Ian Pratt
2004-09-01 13:50 ` Keir Fraser
2004-09-01 21:48 ` Christian Limpach
2004-09-01 22:03 ` Keir Fraser
2004-09-03 2:40 ` Ian Pratt
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.