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

From: Phillip Susi
Date: Fri Feb 10 2006 - 00:17:37 EST


Hrm... when I setup my system on a dmraid controlled hardware fakeraid raid-0, I just gave grub a suitable geometry command since it couldn't auto detect it. I suppose this would make that unnecessary.

I think that ultimately, grub shouldn't care about the geometry since that information has been obsolete for years. If it can't detect the geometry, then it should just assume the system supports LBA and to hell with using made up geometry numbers.


Darrick J. Wong wrote:
Hi again,

I'm trying to install grub on a device-mapper RAID1 array that I set up via dmraid (in other words, a bootable software fakeraid). Since dm doesn't implement the HDIO_GETGEO ioctl, 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.

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. Granted, the notion of cylinders, heads and sectors is silly on a RAID array, but with this patch, interested programs can obtain CHS data that's somewhat close to correct; this seems to be a better option than having each program make up its own potentially different geometry, or making an arbitrary guess. Assuming that all of the programs that need to know CHS geometry will query the kernel via HDIO_GETGEO, this patch makes it so that all of those programs end up using the same geometry.

The patch applies cleanly against 2.6.15.3; if there aren't any objections then I'm submitting this for upstream. However, I'm all ears for suggestions.

Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>

--Darrick


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