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

[Phillip Susi <psusi@cfl.rr.com>]

Alasdair G Kergon wrote:
> 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.
>
>   

That is what it did before.  By failing the ioctl, that indicates that 
the geometry is unknown, and that causes problems for grub. 

> > 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?
>
>   

Yes, I think this could also be fixed on grub's end.  It seems that 
fdisk assumes usable default values for the geometry but grub has 
different defaults that cause it problems.  I think that the defaults 
could be modified in grub so that it will work when HDIO_GETGEO fails. 

> > 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!
>
>   

There is no 'right' or 'wrong' geometry; it is all made up anyhow. 

> > 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.)

Except that most user space tools are not aware of dm and shouldn't need 
to be.

In this case, I think the correct solution is to patch grub so that if 
there is already a valid MBR on the disk, it should take the geometry 
from there.  If it is creating a brand new MBR, then it should use the 
geometry from HDIO_GETGEO and if that fails, make up sensible defaults 
like fdisk does. 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/