Re: [PATCH] Support HDIO_GETGEO on device-mapper volumes
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Date: Fri, 10 Feb 2006 10:12:27 -0500
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: Support HDIO_GETGEO on device-mapper volumes
- From: Molle Bestefich
- Re: Support HDIO_GETGEO on device-mapper volumes
- References:
- [PATCH] Support HDIO_GETGEO on device-mapper volumes
- From: Darrick J. Wong
- Re: [PATCH] Support HDIO_GETGEO on device-mapper volumes
- From: Alasdair G Kergon
- [PATCH] Support HDIO_GETGEO on device-mapper volumes
- Prev by Date: Re: [PATCH] Support HDIO_GETGEO on device-mapper volumes
- Next by Date: [PATCH] fbdev: Fix typo in fbmem.c
- Previous by thread: Re: [PATCH] Support HDIO_GETGEO on device-mapper volumes
- Next by thread: Re: Support HDIO_GETGEO on device-mapper volumes
- Index(es):
Relevant Pages
|
