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/
Home Products Support Community News


Re: [Xen-users] EVMS in dom-U

To: Jim Henderson <his_jimboness@xxxxxxxx>
Subject: Re: [Xen-users] EVMS in dom-U
From: Steve Dobbelstein <steved@xxxxxxxxxx>
Date: Fri, 2 Dec 2005 09:46:57 -0600
Cc: evms-devel@xxxxxxxxxxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 02 Dec 2005 15:47:06 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <438F82F6.7070003@xxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Jim Henderson <his_jimboness@xxxxxxxx> wrote on 12/01/2005 05:10:46 PM:

> Steve,
> The patch applied perfectly to EVMS 2.5.3 (I decided to upgrade from
> 2.5.2 while I was at it) but unfortunately there's still a problem.
> Now, instead of "Function not implemented." I'm getting "Invalid
> ---
> Dec 01 22:59:28 samba _8_ LocalDskMgr: get_geometry: Error getting
> geometry for disk sda: 22: Invalid argument.
> ---
> In addition (not sure if this helps), I've found that hdparm has
> problems getting geometry in my domU too:
> ---
> samba ~ # hdparm /dev/sda
> /dev/sda:
>  readonly     =  0 (off)
>  readahead    = 256 (on)
>  HDIO_GETGEO failed: Function not implemented
> ---
> Any ideas?  Thanks for your help so far.

Hi, Jim.

Since hdparam is also getting an error on the HDIO_GETGEO ioctl, my guess
is that the Xen driver for the disk is not handling the ioctl.  So, looking
at the Xen source, I see that in blkif_ioctl() in
linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c that the case for
HDIO_GETGEO just does "return -ENOSYS;" with a comment that says "return
ENOSYS to use defaults".  Looks like the ENOSYS is making its way back to
hdparam with no defaults set.

EVMS gets a different error code because it first tries the HDIO_GETGEO
ioctl, which fails with ENOSYS, then it tries the HDIO_GETGEO_BIG ioctl (an
old, deprecated ioctl) which blkif_ioctl() doesn't handle and returns its
default -EINVAL.

Taking a quick look at the fdisk code, it appears fdisk ignores errors from
the HDIO_GETGEO ioctl and uses the defaults of 255 heads and 63 sectors per
track.  (It can get the settings of heads and sectors from several ways:
user input, the partition table, or HDIO_GETGEO ioctl, in that order.  If
all three of those are not set, it uses the defaults.)  It always
calculates the number of cylinders from the disk size, the number of heads,
and number of sectors per track.

I see two ways to fix this.  One is to have the Xen blkif_ioctl() return
zeroes for the geometry and return a zero return code.  Other Linux block
drivers do that, and EVMS handles that situation.  The other fix is to
change EVMS to behave like fdisk and use defaults if the ioctls return
error codes.

Anyone on the list have thoughts on this issue?

Steve D.

Xen-users mailing list

<Prev in Thread] Current Thread [Next in Thread>