What does all of this mean? For Linux users only one thing: that they must make sure that LILO and fdisk use the right geometry where `right' is defined for fdisk as the geometry used by the other operating systems on the same disk, and for LILO as the geometry that will enable successful interaction with the BIOS at boot time. (Usually these two coincide.)
How does fdisk know about the geometry?
It asks the kernel, using the HDIO_GETGEO ioctl.
But the user can override the geometry interactively
or on the command line.
How does LILO know about the geometry?
It asks the kernel, using the HDIO_GETGEO ioctl.
But the user can override the geometry using the `disk=' option.
One may also give the linear option to LILO, and it will store
LBA addresses instead of CHS addresses in its map file,
and find out of the geometry to use at boot time (by using
INT 13 Function 8 to ask for the drive geometry).
How does the kernel know what to answer?
Well, first of all, the user may have specified an explicit
geometry with a `hd=cyls,heads,secs'
command line option. And otherwise the kernel will ask the hardware.
Let me elaborate. The IDE driver has four sources for information about the geometry. The first (G_user) is the one specified by the user on the command line. The second (G_bios) is the BIOS Fixed Disk Parameter Table (for first and second disk only) that is read on system startup, before the switch to 32-bit mode. The third (G_phys) and fourth (G_log) are returned by the IDE controller as a response to the IDENTIFY command - they are the `physical' and `current logical' geometries.
On the other hand, the driver needs two values for the geometry:
on the one hand G_fdisk, returned by a HDIO_GETGEO ioctl, and
on the other hand G_used, which is actually used for doing I/O.
Both G_fdisk and G_used are initialized to G_user if given, to
G_bios when this information is present according to CMOS, and to
to G_phys otherwise. If G_log looks reasonable then G_used is set
to that. Otherwise, if G_used is unreasonable and G_phys looks
reasonable then G_used is set to G_phys. Here `reasonable' means
that the number of heads is in the range 1-16.
To say this in other words: the command line overrides the BIOS, and will determine what fdisk sees, but if it specifies a translated geometry (with more than 16 heads), then for kernel I/O it will be overridden by output of the IDENTIFY command.
The situation for SCSI is slightly different, as the SCSI commands
already use logical block numbers, so a `geometry' is entirely
irrelevant for actual I/O.
However, the format of the partition table is still the same,
so fdisk has to invent some geometry, and also uses HDIO_GETGEO here -
indeed, fdisk does not distinguish between IDE and SCSI disks.
As one can see from the detailed description below, the various
drivers each invent a somewhat different geometry. Indeed, one big mess.
If you are not using DOS or so, then avoid all extended translation settings, and just use 64 heads, 32 sectors per track (for a nice, convenient 1 MB per cylinder), if possible, so that no problems arise when you move the disk from one controller to another. Some SCSI disk drivers (aha152x, pas16, ppa, qlogicfas, qlogicisp) are so nervous about DOS compatibility that they will not allow a Linux-only system to use more than about 8 GB. This is a bug.
What is the real geometry? The easiest answer is that there is no such thing. And if there were, you wouldn't want to know, and certainly NEVER, EVER tell fdisk or LILO or the kernel about it. It is strictly a business between the SCSI controller and the disk. Let me repeat that: only silly people tell fdisk/LILO/kernel about the true SCSI disk geometry.
But if you are curious and insist, you might ask the disk itself. There is the important command READ CAPACITY that will give the total size of the disk, and there is the MODE SENSE command, that in the Rigid Disk Drive Geometry Page (page 04) gives the number of cylinders and heads (this is information that cannot be changed), and in the Format Page (page 03) gives the number of bytes per sector, and sectors per track. This latter number is typically dependent upon the notch, and the number of sectors per track varies - the outer tracks have more sectors than the inner tracks. The Linux program scsiinfo will give this information. There are many details and complications, and it is clear that nobody (probably not even the operating system) wants to use this information. Moreover, as long as we are only concerned about fdisk and LILO, one typically gets answers like C/H/S=4476/27/171 - values that cannot be used by fdisk because the partition table reserves only 10 resp. 8 resp. 6 bits for C/H/S.
Then where does the kernel HDIO_GETGEO get its information from?
Well, either from the SCSI controller, or by making an educated guess.
Some drivers seem to think that we want to know `reality', but
of course we only want to know what the DOS or OS/2 FDISK
(or Adaptec AFDISK, etc) will use.
Note that Linux fdisk needs the numbers H and S of heads and sectors per track to convert LBA sector numbers into c/h/s addresses, but the number C of cylinders does not play a role in this conversion. Some drivers use (C,H,S) = (1023,255,63) to signal that the drive capacity is at least 1023*255*63 sectors. This is unfortunate, since it does not reveal the actual size, and will limit the users of most fdisk versions to about 8 GB of their disks - a real limitation in these days.
In the description below, M denotes the total disk capacity, and C, H, S the number of cylinders, heads and sectors per track. It suffices to give H, S if we regard C as defined by M / (H*S).
By default, H=64, S=32.
H=64, S=32.
H=64, S=32 unless C > 1024, in which case H=255, S=63, C = min(1023, M/(H*S)). (Thus C is truncated, and H*S*C is not an approximation to the disk capacity M. This will confuse most versions of fdisk.) The ppa.c code uses M+1 instead of M and says that due to a bug in sd.c M is off by 1.
H=64, S=32 unless C > 1024 and moreover the `> 1 GB' option in the BIOS is enabled, in which case H=255, S=63.
Ask the controller which of two possible translation schemes is in use, and use either H=255, S=63 or H=64, S=32. In the former case there is a boot message "aha1542.c: Using extended bios translation".
H=64, S=32 unless C > 1024, and moreover either the "extended" boot parameter was given, or the `extended' bit was set in the SEEPROM or BIOS, in which case H=255, S=63.
H=64, S=32 unless C >= 1024, and moreover extended translation was enabled on the controller, in which case if M < 2^22 then H=128, S=32; otherwise H=255, S=63. However, after making this choice for (C,H,S), the partition table is read, and if for one of the three possibilities (H,S) = (64,32), (128,32), (255,63) the value endH=H-1 is seen somewhere then that pair (H,S) is used, and a boot message is printed "Adopting Geometry from Partition Table".
Find the geometry information in the BIOS Drive Parameter Table, or read the partition table and use H=endH+1, S=endS for the first partition, provided it is nonempty, or use H=64, S=32 for M < 2^21 (1 GB), H=128, S=63 for M < 63*2^17 (3.9 GB) and H=255, S=63 otherwise.
Use the first of (H,S) = (64,32), (64,63), (128,63), (255,63) that will make C <= 1024. In the last case, truncate C at 1023.
Read C,H,S from the disk. (Horrors!) If C or S is too large, then put S=17, H=2 and double H until C <= 1024. This means that H will be set to 0 if M > 128*1024*17 (1.1 GB). This is a bug.
One of three mappings ((H,S) = (16,63), (64,32), (64,63)) is used depending on the controller mapping mode.
Look at the partition table. Since by convention partitions end
on a cylinder boundary, we can, given end = (endC,endH,endS)
for any partition, just put H = endH+1 and S = endS. (Recall
that sectors are counted from 1.)
More precisely, the following is done.
If there is a nonempty partition, pick the partition with the largest beginC.
For that partition, look at end+1, computed
both by adding start and length and by assuming that this
partition ends on a cylinder boundary. If both values agree, or
if endC = 1023 and start+length is an integral multiple of
(endH+1)*endS,
then assume that this partition really was aligned on a cylinder
boundary, and put H = endH+1 and S = endS.
If this fails, either because there are no partitions, or because
they have strange sizes, then look only at the disk capacity M.
Algorithm: put H = M/(62*1024) (rounded up), S = M/(1024*H)
(rounded up), C = M/(H*S) (rounded down).
This has the effect of producing a (C,H,S) with C at most 1024
and S at most 62.