Re: Support HDIO_GETGEO on device-mapper volumes

Molle Bestefich wrote:
It would be better to make the decision once and for all, in one place.

It would be even better for the HDIO_GETGEO call to return the same
geometry that the BIOS uses, so that Grub is handed numbers that
actually mean *something*.

The problem is that the numbers don't actually mean anything, even to the bios. They are only there for backward compatibility with real mode software that makes int 13 calls. The bios just fakes the geometry anyway so it can emulate something, but there really is no meaning to the geometry; it's just smoke and mirrors.

In the case of dm, which geometry should it report? In some cases it might make sense to pass up the values from the bios, but in most, there is no sensible way to choose what to report, and any value you do report is meaningless gibberish anyhow, so why bother at all? Just bring the apps still using it ( grub, lilo ) into the 21st century and have them stop using these meaningless values in the first place. LBA has been around for a good 10 years now, so I think it is safe to no longer require these made up values to support CHS addressing.
When 'dmraid' has assembled an array, it should find the matching BIOS
drive in /proc/bios/int13_dev* and then it should tell device-mapper
to present that geometry to whomever asks via HDIO_GETGEO.
dmraid is only one client of the kernel device mapper. It has numerous uses that have nothing to do with hardware fakeraid, including LVM. In the special case of dmraid there is a bios int13 dev for the raid that provides some geometry, but why hack dm for this special case when it is totally unnecessary in the first place?
And while we're at it, <some component> should do the same for eg.
/dev/hd?. It's very annoying trying to fix up a harddrive's partition
table when the numbers you see in Linux is different to the numbers
you'll see when rebooting into DOS, or Windows XP, or whatever it is
that's on the disk you're trying to fix.
-

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

Relevant Pages

  • RE: Drive Geometry -- confusion.
    ... > Drive Geometry confusion. ... > The following are the only settings offered by my BIOS: ... limitations of "BIOS" disk addressing, ... down the DEL key) may tell you about some ATA/IDE drives, ...
    (freebsd-questions)
  • Re: a few words on BIOS/FDISK geometry
    ... > There are two common ways in which disk sector addresses are expressed. ... > The system BIOS provides a basic disk access facility sometimes called ... > writing and obtaining disk parameters such as geometry. ... > The disk geometry assumed by the basic int13 functions is what we mean ...
    (freebsd-questions)
  • Re: Support HDIO_GETGEO on device-mapper volumes
    ... most of the time these days the bogus values do match the bios values. ... If grub is using HDIO_GETGEO then yea, it should just use the geometry in the MBR instead. ... It should assume that the values stored in the MBR already are correct, since if they weren't, the system wouldn't boot anyhow, and use those rather than ask the kernel. ... disk in a compatible way. ...
    (Linux-Kernel)
  • Geometry and Mirror
    ... I used to install FreeBSD and when it came to fdisk, ... If this geometry is incorrect or you are ... The BIOS setting was autodetect for both drives. ... "FreeBSD does not use the BIOS, and does not know the ``logical BIOS ...
    (freebsd-questions)
  • Re: Support HDIO_GETGEO on device-mapper volumes
    ... fdisk assumes usable default values for the geometry but grub has ... could be modified in grub so that it will work when HDIO_GETGEO fails. ... I don't know that there would be any easy way for the kernel to know which BIOS drive corresponds to the device, and the device may be one that's not recognized by the BIOS at all and therefore has no BIOS device ... There were problems with this that surfaced sometime after the release of the 2.6 kernel, where installing Fedora Core 2 on a dual-boot system with Windows would render Windows unbootable. ...
    (Linux-Kernel)