Re: Support HDIO_GETGEO on device-mapper volumes

Re: Support HDIO_GETGEO on device-mapper volumes

[Robert Hancock]

Molle Bestefich wrote:
> Phillip Susi wrote:
>> 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.
> 
> 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 numbers don't really mean anything in any case, it's a matter of 
choosing one fiction over another. 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 (ex: Linux software RAID).

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. As I recall, it seems that 
even though it doesn't really use CHS, the Windows boot loader somehow 
cares that the CHS geometry in the partition table and/or MBR matches 
the BIOS reported geometry and chokes if it doesn't. As I see it, the 
solution to that would be to not touch the existing geometry if there's 
already one there, and if not, then try to find out the BIOS geometry 
for the drive somehow and put that in.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

[PATCH] Support HDIO_GETGEO on device-mapper volumes

[Darrick J. Wong]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

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@us.ibm.com>

--Darrick

[-- Attachment #2: dm-getgeo_1.patch --]
[-- Type: text/x-patch, Size: 1751 bytes --]

diff -Naurp a/drivers/md/dm.c b/drivers/md/dm.c
--- a/drivers/md/dm.c	2006-01-14 22:16:02.000000000 -0800
+++ b/drivers/md/dm.c	2006-02-09 14:05:18.000000000 -0800
@@ -17,6 +17,7 @@
 #include <linux/mempool.h>
 #include <linux/slab.h>
 #include <linux/idr.h>
+#include <linux/hdreg.h>
 
 static const char *_name = DM_NAME;
 
@@ -223,6 +224,47 @@ static int dm_blk_close(struct inode *in
 	return 0;
 }
 
+static int dm_blk_ioctl(struct inode * inode, struct file * filp,
+			unsigned int cmd, unsigned long arg)
+{
+	struct block_device *bdev = inode->i_bdev;
+	struct hd_geometry __user *loc = (void __user *)arg;
+	struct mapped_device *md;
+	int diskinfo[4];
+
+	if (cmd == HDIO_GETGEO) {
+		if (!arg)
+			return -EINVAL;
+
+		/* Make up some fake geometry. */
+		md = bdev->bd_disk->private_data;
+		diskinfo[0] = 0x40;	/* 1 << 6 */
+		diskinfo[1] = 0x20;	/* 1 << 5 */
+		diskinfo[2] = md->disk->capacity >> 11;
+		diskinfo[3] = 0;
+
+		/* cylinder count too big? */
+		if (diskinfo[2] > 65536) {
+			diskinfo[0] = 255;
+			diskinfo[1] = 63;
+			diskinfo[2] = md->disk->capacity / 16065; /* 255*63 */
+		}
+
+		if (put_user(diskinfo[0], &loc->heads))
+			return -EFAULT;
+		if (put_user(diskinfo[1], &loc->sectors))
+			return -EFAULT;
+		if (put_user(diskinfo[2], &loc->cylinders))
+			return -EFAULT;
+		if (put_user(diskinfo[3], &loc->start))
+			return -EFAULT;
+
+		return 0;
+	}
+
+	return -ENOTTY;
+}
+
 static inline struct dm_io *alloc_io(struct mapped_device *md)
 {
 	return mempool_alloc(md->io_pool, GFP_NOIO);
@@ -1179,6 +1221,7 @@ int dm_suspended(struct mapped_device *m
 static struct block_device_operations dm_blk_dops = {
 	.open = dm_blk_open,
 	.release = dm_blk_close,
+	.ioctl = dm_blk_ioctl,
 	.owner = THIS_MODULE
 };
 

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

[Alasdair G Kergon]

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.

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

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

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

Alasdair
--
agk@redhat.com

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

[Phillip Susi]

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. 

Re: Support HDIO_GETGEO on device-mapper volumes

[Molle Bestefich]

Phillip Susi wrote:
> 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.

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

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.

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.

Re: Support HDIO_GETGEO on device-mapper volumes

[Phillip Susi]

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

Re: Support HDIO_GETGEO on device-mapper volumes

[Molle Bestefich]

Phillip Susi wrote:
> 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.

Obviously.

That doesn't stop the Linux kernel and device-mapper from presenting
usable numbers to user space tools.

What are "usable numbers"?
The only usable numbers are the exact ones that the BIOS uses, because
they are the only CHS numbers that have a purpose:

The purpose of those numbers is backwards compatibility with DOS and
Windows.  Stuff like PartitionMagic, FreeDOS, odd boot loaders
(including Windows XP's), weird implementations of fdisk, etc.

And that's the reason that the kernel and device mapper should either
represent the numbers that the BIOS currently uses, or nothing at all.

Fair'n'square..

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

It does, I've come across a few.

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

The statement that "any value is gibberish" is plain wrong, since the
BIOS translations are useful values under some circumstances.

In cases where it does make sense, you want a consistent and well
maintained method of matching BIOS drives to devices and reporting
BIOS numbers.

In cases where it does not make sense, you just want to return error
and let the app handle it.

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

LILO is already fit for fight if you use the right flag.

Good idea to fix GRUB.
The GRUB code does look like a mess to me, though.
An ETA on GRUB2 would be nice, or an alternate source tree where
people could improve on the existing GRUB..

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

If you rip all CHS out of the kernel right now, user space tools has
to make guesses when mucking with partition tables.  Any attempts to
make Linux <whatever>fdisk compatible with other fdisk's will be
futile.  Stuff like for example placing a partition on a (virtual)
cylinder boundary is going to break when Linux <whatever>fdisk
translates LBA to CHS in one way (since the kernel doesn't provide a
meaningful value) and your BIOS does it another.

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

Ok, the better approach might be to destroy HDIO_GETGEO entirely and
tell userspace apps to use /sys/firmware/edd/int13_dev instead.  It
provides for a cleaner implementation.

But then again, that breaks compatibility with current tools.

A good way to get the ball rolling could be if we could all agree that
there are a number of tools that need the BIOS CHS numbers.  Then we
can decide where the universal logic that attempts to guess which
devices are which should go.  Then a proper implementation could be
discussed and conjured, and dmraid, <whatever>fdisk, perhaps LILO/GRUB
etc. could be made dependant on it.  And THEN the HDIO_GETGEO could be
ripped...

Anyway, just a personal idea, your concept of completely nuking CHS
from the kernel right now might be acceptable as well.

Re: Support HDIO_GETGEO on device-mapper volumes

[Phillip Susi]

Molle Bestefich wrote:
> 
> Obviously.
> 
> That doesn't stop the Linux kernel and device-mapper from presenting
> usable numbers to user space tools.
> 
> What are "usable numbers"?
> The only usable numbers are the exact ones that the BIOS uses, because
> they are the only CHS numbers that have a purpose:
> 
> The purpose of those numbers is backwards compatibility with DOS and
> Windows.  Stuff like PartitionMagic, FreeDOS, odd boot loaders
> (including Windows XP's), weird implementations of fdisk, etc.
> 
> And that's the reason that the kernel and device mapper should either
> represent the numbers that the BIOS currently uses, or nothing at all.
> 
> Fair'n'square..
> 

Exactly!  If guesses have to be made because the correct values can not 
be obtained from the bios, then it should be fdisk/parted/whatever that 
has to make that guess ( or ask the user for manual intervention ), not 
the kernel.

> The statement that "any value is gibberish" is plain wrong, since the
> BIOS translations are useful values under some circumstances.
> 

In certain dm configurations ( specifically, when used for dmraid 
assisted hardware fakeraid ) it might make sense, but for many dm 
configurations it won't because the bios can't access the volume anyhow, 
so it hardly makes any sense to associate a bios geometry with it. 
That's what I meant by gibberish; if the drive isn't seen by the bios, 
any geometry you come up with has no meaning.

> In cases where it does make sense, you want a consistent and well
> maintained method of matching BIOS drives to devices and reporting
> BIOS numbers.
> 

Right.  Unfortunately, it seems this was specifically removed from the 
kernel because it was problematic, which I don't really mind since CHS 
addressing needs to die anyhow.

> In cases where it does not make sense, you just want to return error
> and let the app handle it.
> 

Bingo.

>> 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.
> 
> LILO is already fit for fight if you use the right flag.
> 
> Good idea to fix GRUB.
> The GRUB code does look like a mess to me, though.
> An ETA on GRUB2 would be nice, or an alternate source tree where
> people could improve on the existing GRUB..
> 

IIRC, grub just uses the geometry it finds in the MBR, or you can 
override with the geometry command.

>> 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.
> 
> If you rip all CHS out of the kernel right now, user space tools has
> to make guesses when mucking with partition tables.  Any attempts to
> make Linux <whatever>fdisk compatible with other fdisk's will be
> futile.  Stuff like for example placing a partition on a (virtual)
> cylinder boundary is going to break when Linux <whatever>fdisk
> translates LBA to CHS in one way (since the kernel doesn't provide a
> meaningful value) and your BIOS does it another.
> 

Right, but this has already been done.  The values currently in the 
kernel are not taken from the bios, so as you said, either report it 
right, or don't report it at all.

In the case where fdisk must initialize a brand new MBR, then it should 
assume sensible defaults and allow you to override.  Most of the time 
though, people will already have a drive formatted by windows which will 
have the correct geometry written in the MBR, so the linux tools will 
just use that.

> 
> Ok, the better approach might be to destroy HDIO_GETGEO entirely and
> tell userspace apps to use /sys/firmware/edd/int13_dev instead.  It
> provides for a cleaner implementation.
> 
> But then again, that breaks compatibility with current tools.
> 

They are already broken since the HDIO_GETGEO isn't returning the values 
from the bios.  What is the status of edd?  Is that officially supported 
or is it depreciated?  If it is ok to use, then it would probably be a 
good place for fdisk to get that info from, though it's going to have to 
figure out which int13_dev ( if any ) corresponds to the device you are 
partitioning.  Sensible defaults for well known devices like /dev/hda 
should cover most cases, but not all.  For instance, I recently 
configured a server's bios to disable the primary ide channel because 
that disk was bad and I needed to boot from the second mirrored drive, 
so /dev/hdb actually corresponded to bios device 80, not /dev/hda.

> A good way to get the ball rolling could be if we could all agree that
> there are a number of tools that need the BIOS CHS numbers.  Then we
> can decide where the universal logic that attempts to guess which
> devices are which should go.  Then a proper implementation could be
> discussed and conjured, and dmraid, <whatever>fdisk, perhaps LILO/GRUB
> etc. could be made dependant on it.  And THEN the HDIO_GETGEO could be
> ripped...
> 

Aye, well put.  So let's see here.  As far as I can see, the only tools 
that need this information are ones that can create MBRs, so that's 
fdisk, cfdisk, parted, and friends.  Everything else can/should just use 
the values listed in the MBR.

Agree?

> Anyway, just a personal idea, your concept of completely nuking CHS
> from the kernel right now might be acceptable as well.
> 

Re: Support HDIO_GETGEO on device-mapper volumes

[Molle Bestefich]

Phillip Susi wrote:
> Right.  Unfortunately, it seems this was specifically removed from the
> kernel because it was problematic,

Ok.  Got an archive link or other references?

> IIRC, grub just uses the geometry it finds in the MBR, or you can
> override with the geometry command.

Last I checked, grub used HDIO_GETGEO when running under Linux.

Which makes it pretty useless if what you say above is true.  Except
of course in the particular cases where the bogus values that the
Linux kernel makes up happens to be correct.

Horribly unsafe way for a boot loader to function, if you ask me.
(Not really grub's fault, more the Linux kernel it seems.)


> In the case where fdisk must initialize a brand new MBR, then it should
> assume sensible defaults and allow you to override.

There are no sensible defaults.

There's the translation that the BIOS (and thus DOS, PartitionMagic,
yadda) uses, and then there's everything else, which is wrong.

It won't do you any good to fill in "sensible defaults", since if it
doesn't comply with what the BIOS decides (or you decide in the BIOS
setup as is the case on my Compaq), those old programs just won't
work.
And Linux doesn't care about CHS values anyway, so no point in filling
in hocus pocus "sensible" stuff on that account.


> Most of the time though, people will already have a drive formatted by
> windows which will have the correct geometry written in the MBR,
> so the linux tools will just use that.

Yes, well, but it WOULD be nice if Linux was able to partition the
disk in a compatible way.

It's a stupid feature that one HAS to first boot a Windows CD,
partition the harddrive and install Windows and then install Linux
afterwards.  Should be doable the other way around.

Moreover, the MBR values are not guaranteed to be correct if you want
to partition your disk in a way compatible with the BIOS in your
system.  The disk might have been moved from another PC (using another
translation), in which case the MBR values will be wrong.  Another
example is dd'ing an entire drive to a larger drive - the BIOS might
use different translation for the two drives, and the MBR values will
be incorrect.

Ok, quite theoretical perhaps, but the main idea is that if you want
to partition a disk to be compatible with DOS, Windows etc. on the PC
the disk is sitting in, you have to use BIOS, not MBR values.

(MBR values can be good for other things, for example preparing a disk
for a different system.)


> > Ok, the better approach might be to destroy HDIO_GETGEO entirely and
> > tell userspace apps to use /sys/firmware/edd/int13_dev instead.  It
> > provides for a cleaner implementation.
> >
> > But then again, that breaks compatibility with current tools.
>
> They are already broken since the HDIO_GETGEO isn't returning the values
> from the bios.

Ok.

> What is the status of edd?  Is that officially supported
> or is it depreciated?

Can't imagine why it would be deprecated.

> If it is ok to use, then it would probably be a
> good place for fdisk to get that info from, though it's going to have to
> figure out which int13_dev ( if any ) corresponds to the device you are
> partitioning.

Comparing the first and last sector should do.
If not, we can error out without mapping certain devices.
If that's a problem to any users, they can use a tool to write unique
sigs to the start ~2kB or end ~2kB of disks..

> Sensible defaults for well known devices like /dev/hda
> should cover most cases, but not all.

Nah, I don't think that's a good idea.
Figure out the right mappings or error out, don't guess.

> For instance, I recently
> configured a server's bios to disable the primary ide channel because
> that disk was bad and I needed to boot from the second mirrored drive,
> so /dev/hdb actually corresponded to bios device 80, not /dev/hda.

And there are far more weird and obscure cases than this.

> > A good way to get the ball rolling could be if we could all agree that
> > there are a number of tools that need the BIOS CHS numbers.  Then we
> > can decide where the universal logic that attempts to guess which
> > devices are which should go.  Then a proper implementation could be
> > discussed and conjured, and dmraid, <whatever>fdisk, perhaps LILO/GRUB
> > etc. could be made dependant on it.  And THEN the HDIO_GETGEO could be
> > ripped...
>
> Aye, well put.  So let's see here.  As far as I can see, the only tools
> that need this information are ones that can create MBRs, so that's
> fdisk, cfdisk, parted, and friends.  Everything else can/should just use
> the values listed in the MBR.
>
> Agree?

GRUB and LILO might want to see CHS values too, in case you're
preparing a boot loader on a PC without int13 LBA extensions.  Ok,
that's pretty far out, but could happen :-).  If nothing else, then
because the user accidentally chose CHS mode.

dmraid might want to see the CHS values, in case there's an ATARAID
adapter which might or might not be capping drives to their last GB,
and dmraid wants to know whether the capping feature is enabled.  Not
sure if this is a sensible way to gather that information, but it
might be the only one for some adapters (who knows).

Can't think of anything else on top of my head (not saying that there
isn't any :-)).

Re: Support HDIO_GETGEO on device-mapper volumes

[Phillip Susi]

Molle Bestefich wrote:
> Ok.  Got an archive link or other references?
> 

Unfortunately, no.

>> IIRC, grub just uses the geometry it finds in the MBR, or you can
>> override with the geometry command.
> 
> Last I checked, grub used HDIO_GETGEO when running under Linux.
> 
> Which makes it pretty useless if what you say above is true.  Except
> of course in the particular cases where the bogus values that the
> Linux kernel makes up happens to be correct.
> 

Exactly.  Oddly enough though, 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.  That probably 
explains why I had to issue the geometry command explicitly when 
installing grub on my hardware fakeraid.  I guess grub assumed some odd 
defaults when HDIO_GETGEO failed.  I should investigate that further.

> Horribly unsafe way for a boot loader to function, if you ask me.
> (Not really grub's fault, more the Linux kernel it seems.)
> 

It is unsafe, but it is also partly grub's fault since it shouldn't be 
calling HDIO_GETGEO in the first place.  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.

> 
>> In the case where fdisk must initialize a brand new MBR, then it should
>> assume sensible defaults and allow you to override.
> 
> There are no sensible defaults.
> 

Sure there are: 255 heads and 63 sectors.  Most bioses will map most 
modern hard disks ( > 8 GB ) to this geometry.  Fdisk seems to use this 
default, and most of the time, it is correct.

> There's the translation that the BIOS (and thus DOS, PartitionMagic,
> yadda) uses, and then there's everything else, which is wrong.
> 
> It won't do you any good to fill in "sensible defaults", since if it
> doesn't comply with what the BIOS decides (or you decide in the BIOS
> setup as is the case on my Compaq), those old programs just won't
> work.
> And Linux doesn't care about CHS values anyway, so no point in filling
> in hocus pocus "sensible" stuff on that account.
> 

You have to use SOMETHING and since most of the time it will be 255/63, 
the tools may as well default to that, possibly with a warning informing 
the user that they may need to change that to be able to dual boot with 
windows.

> 
>> Most of the time though, people will already have a drive formatted by
>> windows which will have the correct geometry written in the MBR,
>> so the linux tools will just use that.
> 
> Yes, well, but it WOULD be nice if Linux was able to partition the
> disk in a compatible way.
> 
> It's a stupid feature that one HAS to first boot a Windows CD,
> partition the harddrive and install Windows and then install Linux
> afterwards.  Should be doable the other way around.
> 

You can do it the other way around, you just have to make sure that 
linux's fdisk guesses the correct geometry, which it will most of the 
time.

> Moreover, the MBR values are not guaranteed to be correct if you want
> to partition your disk in a way compatible with the BIOS in your
> system.  The disk might have been moved from another PC (using another
> translation), in which case the MBR values will be wrong.  Another
> example is dd'ing an entire drive to a larger drive - the BIOS might
> use different translation for the two drives, and the MBR values will
> be incorrect.
> 

Correct, which is why fdisk needs to allow you to override the geometry, 
but most of the time users won't run into this so it is sensible to 
assume sensible defaults.

> Ok, quite theoretical perhaps, but the main idea is that if you want
> to partition a disk to be compatible with DOS, Windows etc. on the PC
> the disk is sitting in, you have to use BIOS, not MBR values.
> 
> (MBR values can be good for other things, for example preparing a disk
> for a different system.)
> 
> 
>> They are already broken since the HDIO_GETGEO isn't returning the values
>> from the bios.
> 
> Ok.
> 
>> What is the status of edd?  Is that officially supported
>> or is it depreciated?
> 
> Can't imagine why it would be deprecated.
> 
>> If it is ok to use, then it would probably be a
>> good place for fdisk to get that info from, though it's going to have to
>> figure out which int13_dev ( if any ) corresponds to the device you are
>> partitioning.
> 
> Comparing the first and last sector should do.
> If not, we can error out without mapping certain devices.
> If that's a problem to any users, they can use a tool to write unique
> sigs to the start ~2kB or end ~2kB of disks..
> 

Good idea.  It is a bit kludgey, but it should work well enough.  It 
also requires being able to call int 13 to read the first and last sector.

>> Sensible defaults for well known devices like /dev/hda
>> should cover most cases, but not all.
> 
> Nah, I don't think that's a good idea.
> Figure out the right mappings or error out, don't guess.
> 
>> For instance, I recently
>> configured a server's bios to disable the primary ide channel because
>> that disk was bad and I needed to boot from the second mirrored drive,
>> so /dev/hdb actually corresponded to bios device 80, not /dev/hda.
> 
> And there are far more weird and obscure cases than this.
> 
> 
> GRUB and LILO might want to see CHS values too, in case you're
> preparing a boot loader on a PC without int13 LBA extensions.  Ok,
> that's pretty far out, but could happen :-).  If nothing else, then
> because the user accidentally chose CHS mode.
> 

They should be getting the geometry from the MBR anyhow since if they do 
choose a value different from those used to create the partition table, 
it will screw the pooch.

> dmraid might want to see the CHS values, in case there's an ATARAID
> adapter which might or might not be capping drives to their last GB,
> and dmraid wants to know whether the capping feature is enabled.  Not
> sure if this is a sensible way to gather that information, but it
> might be the only one for some adapters (who knows).
> 

I don't follow.  dmraid doesn't know or care about ATARAID adapters that 
may or may not be hiding the tail end of the disk, that is taken care of 
by the driver, which just disables the hiding.  dmraid just looks at the 
tail of the disks for the bios configuration block and sets up device 
mapper to access the disks.

> Can't think of anything else on top of my head (not saying that there
> isn't any :-)).