Re: [PATCH] Support HDIO_GETGEO on device-mapper volumes

[Alasdair G Kergon <agk@redhat.com>]

On Thu, Feb 09, 2006 at 05:35:12PM -0800, Darrick J. Wong wrote:
> Since dm doesn't implement the HDIO_GETGEO ioctl,

Why should it?  Device-mapper constructs a virtual device and
I think it's completely wrong for it to 'fake' a geometry.

Of course dm could recognise the ioctl - but the default response
should be the one that indicates the geometry is unknown.

> grub assumes that the CHS
> geometry is 620/128/63, which makes it impossible to configure it to
> boot a filesystem that lives beyond the 2GB mark, even if the system
> BIOS supports that.

Surely a problem in grub, not the kernel?

> The attached patch implements a simple ioctl handler that supplies a
> compatible geometry when HDIO_GETGEO is called against a device-mapper
> device.  Its behavior is somewhat similar to what sd_mod does if the
> scsi controller doesn't provide its own geometry. 

What if the dm device is a linear mapping to an sd device that *does*
provide a different geometry?  Then the 'fake' geometry dm would return
with this patch would be wrong!

> this seems to be a better option than having each program make
> up its own potentially different geometry, or making an arbitrary guess.

I disagree - either dm should work out the *correct* geometry to
return for those mappings where a geometry is known and it's sensible
to return one (e.g. linear mapping to the start of certain scsi
devices), or else it should leave it to userspace to decide how to
handle the situation.  (And there's nothing currently stopping
userspace seeing that a dm device is constructed out of a scsi device
and choosing to use the geometry of that underlying device.)

Alasdair
--
agk@redhat.com