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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
