The Linux IDE driver gets the geometry and capacity of a disk
(and lots of other stuff) by using an
ATA IDENTIFY request.
Until recently the driver would not believe the returned value
of lba_capacity if it was more than 10% larger than the capacity
computed by C*H*S. However, by industry agreement
large IDE disks (with more than 16514064 sectors)
return C=16383, H=16, S=63, for a total of 16514064 sectors (7.8 GB)
independent of their actual size, but give their actual size in
lba_capacity.
Recent Linux kernels (2.0.34, 2.1.90) know about this
and do the right thing. If you have an older Linux kernel and do
not want to upgrade, and this kernel only sees 8 GiB of a much larger disk,
then try changing the routine lba_capacity_is_ok in
/usr/src/linux/drivers/block/ide.c into something like
static int lba_capacity_is_ok (struct hd_driveid *id) {
id->cyls = id->lba_capacity / (id->heads * id->sectors);
return 1;
}
As just mentioned, large disks return the geometry C=16383, H=16, S=63 independent of the actual size, while the actual size is returned in the value of LBAcapacity. Some BIOSes do not recognize this, and translate this 16383/16/63 into something with fewer cylinders and more heads, for example 1024/255/63 or 1027/255/63. So, the kernel must not only recognize the single geometry 16383/16/63, but also all BIOS-mangled versions of it. Since 2.2.2 this is done correctly (by taking the BIOS idea of H and S, and computing C = capacity/(H*S)). Usually this problem is solved by setting the disk to Normal in the BIOS setup (or, even better, to None, not mentioning it at all to the BIOS). If that is impossible because you have to boot from it or use it also with DOS/Windows, and upgrading to 2.2.2 or later is not an option, use kernel boot parameters.
If a BIOS reports 16320/16/63, then this is usually done in order to get 1024/255/63 after translation.
There is an additional problem here. If the disk was partitioned
using a geometry translation, then the kernel may at boot time
see this geometry used in the partition table, and report
hda: [PTBL] [1027/255/63]. This is bad, because now the
disk is only 8.4 GB. This was fixed in 2.3.21. Again, kernel
boot parameters will help.
Many disks have jumpers that allow you to choose between a 15-head an a 16-head geometry. The default settings will give you a 16-head disk. Sometimes both geometries address the same number of sectors, sometimes the 15-head version is smaller. There may be a good reason for this setup: Petri Kaukasoina writes: `A 10.1 Gig IBM Deskstar 16 GP (model IBM-DTTA-351010) was jumpered for 16 heads as default but this old PC (with AMI BIOS) didn't boot and I had to jumper it for 15 heads. hdparm -i tells RawCHS=16383/15/63 and LBAsects=19807200. I use 20960/15/63 to get the full capacity.' For the jumper settings, see http://www.storage.ibm.com/techsup/hddtech/hddtech.htm.
Many disks have jumpers that allow you to make the disk appear smaller than it is. A silly thing to do, and probably no Linux user ever wants to use this, but some BIOSes crash on big disks. The usual solution is to keep the disk entirely out of the BIOS setup. But this may be feasible only if the disk is not your boot disk.
The first serious limit was the 4096 cylinder limit (that is, with 16 heads and 63 sectors/track, 2.11 GB). For example, a Fujitsu MPB3032ATU 3.24 GB disk has default geometry 6704/15/63, but can be jumpered to appear as 4092/16/63, and then reports LBAcapacity 4124736 sectors, so that the operating system cannot guess that it is larger in reality. In such a case (with a BIOS that crashes if it hears how big the disk is in reality, so that the jumper is required) one needs boot parameters to tell Linux about the size of the disk.
That is unfortunate. Most disks can be jumpered so as to appear as a 2 GB disk and then report a clipped geometry like 4092/16/63 or 4096/16/63, but still report full LBAcapacity. Such disks will work well, and use full capacity under Linux, regardless of jumper settings.
A more recent limit is the 33.8 GB limit. Linux kernels older than 2.2.14 / 2.3.21 need a patch to be able to cope with IDE disks larger than this.
With an old BIOS and a disk larger than 33.8 GB, the BIOS may hang, and in such cases booting may be impossible, even when the disk is removed from the CMOS settings. See also the BIOS 33.8 GB limit.
Therefore, large IBM and Maxtor disks come with a jumper that make the disk appear as a 33.8 GB disk. For example, the IBM Deskstar 37.5 GB (DPTA-353750) with 73261440 sectors (corresponding to 72680/16/63, or 4560/255/63) can be jumpered to appear as a 33.8 GB disk, and then reports geometry 16383/16/63 like any big disk, but LBAcapacity 66055248 (corresponding to 65531/16/63, or 4111/255/63). Similar things hold for recent large Maxtor disks.
With the jumper present, both the geometry (16383/16/63) and the size
(66055248) are conventional and give no information about the actual size.
Moreover, attempts to access sector 66055248 and above yield I/O errors.
However, on Maxtor drives the actual size can be found and made accessible
using the READ NATIVE MAX ADDRESS and SET MAX ADDRESS commands.
Presumably this is what MaxBlast/EZ-Drive does. Now there is also
a small Linux utility
setmax.c for this, and also a kernel patch has been published.
Recent kernels (2.5.3 or later) do not need patch or setmax;
the config option CONFIG_IDEDISK_STROKE tells the kernel to do this
automatically at boot time.
For drives larger than 137 GB also READ NATIVE MAX ADDRESS returns
a conventional value, namely 0xfffffff, corresponding to 137 GB.
Here READ NATIVE MAX ADDRESS EXT and SET MAX ADDRESS EXT (using
48-bit addressing) are required. The setmax utility does not yet
know about this. A very small patch makes 2.5.3 handle this situation.
Early large Maxtor disks have an additional detail: the J46 jumper for these 34-40 GB disks changes the geometry from 16383/16/63 to 4092/16/63 and does not change the reported LBAcapacity. This means that also with jumper present the BIOS (old Award 4.5*) will hang at boot time. For this case Maxtor provides a utility JUMPON.EXE that upgrades the firmware to make J46 behave as described above.
On recent Maxtor drives the call setmax -d 0 /dev/hdX will
give you max capacity again. However, on slightly older drives a
firmware bug does not allow you to use -d 0, and
setmax -d 255 /dev/hdX returns you to almost full capacity.
For Maxtor D540X-4K, see below.
For IBM things are worse: the jumper really clips capacity
and there is no software way to get it back. The solution is
not to use the jumper but use setmax -m 66055248 /dev/hdX
to software-clip the disk. ("How?" you say - "I cannot boot!".
IBM gives the tip: If a system with Award BIOS hangs during drive
detection: Reboot the system and hold the F4 key to bypass autodetection
of the drive(s). If this doesn't help, find a different computer,
connect the drive to it, and run setmax there. After doing this
you go back to the first machine and are in the same situation as
with jumpered Maxtor disks: booting works, and after getting past
the BIOS either a patched kernel or a setmax -d 0
gets you full capacity.
The Maxtor Diamond Max drives 4K080H4, 4K060H3, 4K040H2 (aka D540X-4K) are identical to the drives 4D080H4, 4D060H3, 4D040H2 (aka D540X-4D), except that the jumper settings differ. A Maxtor FAQ specifies the Master/Slave/CableSelect settings for them, but the capacity clip jumper for the "4K" drives seems to be undocumented. Nils Ohlmeier reports that he experimentally finds that it is the J42 jumper ("reserved for factory use") closest to the power connector. (The "4D" drives use the J46 jumper, like all other Maxtor drives.)
However, it may be that this undocumented jumper acts like the IBM jumper:
the machine boots correctly, but the disk has been clipped to 33 GB
and setmax -d 0 does not help to get full capacity back.
And the IBM solution works: do not use any disk-clipping jumpers, but
first put the disk in a machine with non-broken BIOS, soft-clip it
with setmax -m 66055248 /dev/hdX, then put it back in the
first machine, and after booting run setmax -d 0 /dev/hdX
to get full capacity again.
In the meantime, some docs and pictures have appeared on the Maxtor site, confirming part of the above. Compare