Re: Hard disk geometry

Guest section DW (dwguest@win.tue.nl)
Fri, 22 Oct 1999 01:11:39 +0200 (MET DST)


I'm writing a Partition Magic clone, called GNU parted
(www.gnu.org/software/parted) which NEEDS to know hard disk geometry
to be compatible with other operating systems, using the term loosely.

Linux doesn't seem to be very good at detecting geometry (i.e. sectors
per track, and heads per cylinder). There's a comment in the code
suggesting int 13 be called when Linux is in real mode, because this
is the most reliable way of getting a hard disk's geometry.

Are there any objections to me implementing this? Are there any
preferred alternatives? What's the best way of communicating with
the real-mode code and the driver? How about setting
(but not overriding) kernel parameters?

Andrew Clausen

> which NEEDS to know hard disk geometry

Which hard disk geometry? There are several you can choose between.

> Linux doesn't seem to be very good at detecting geometry.
> There's a comment in the code suggesting int 13 be called

It doesnt work.

I wrote the corresponding patch and asked people to try it.
The results are very dependent on BIOS, BIOS setup, disks present.

For example, suppose that the machine has one SCSI disk and one IDE disk.
Ask the BIOS for the geometry of the first drive. For what disk do you
get answers? Some BIOSes give you the IDE disk first, some BIOSes
give you the SCSI disk first, some BIOSes first give you the disk
the system boots from.

So, in case you get an answer, nobody knows for what disk it is.
But the BIOS will not report on disks not mentioned in the setup.
That is another reason asking the BIOS fails. Some BIOS calls only
work for the first two disks. Again a reason for failure.

And then, even in case of success, the details vary.
Sometimes the BIOS returns the capacity, sometimes it subtracts
the last cylinder, sometimes it subtracts the last cylinder twice.

Some BIOSes are just buggy and return ridiculous results.

If you search you must be able to find my program getbiosdrivedata.c
or so - it has very detailed info on the relevant BIOS calls
and problems. (Otherwise maybe I can find it. I lost a disk last May,
but this program also lives on some mirror sites.)

Conclusion:
1. A disk does not have a geometry, so you are searching for
a nonexistent object.
2. Stay away from the BIOS. Nothing usable can be gotten from it.

Where could you look for this nonexistent geometry?

There is the disk - a good source of information.
There is the partition table - by solving a few equations with
two unknowns you can sometimes conclude what geometry was
used by the program that wrote it.
There is the partition table - some programs assume that
partitions end on cylinder boundaries - it is a heuristic,
but often true.
If all fails then assume 63 sectors/track. A very safe bet.
If you still lack information, assume 255 heads.

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/