Please be careful, last time changes like that were made
it killed my setup:
Heads: 16 Sectors per Track: 63 Cylinders: 2100
Yes, let us be careful - that is also what mlord said,
and I reacted a bit irritated because he knows these things
and would have understood that the change was good, even necessary,
had he thought about it.
Now that you do not seem to know this stuff, and you are not alone,
let me try to explain a bit more.
There are 1-dimensional disk addresses: just give a sector number n.
And there are 3-dimensional disk addresses: give cylinder c, head h,
sector s. If the disk has in total C cylinders, H heads, S sectors/track,
then the conversion is n = c*H*S + h*S + s.
(Yes, I know, some misguided people prefer to start counting sectors
at 1 instead of 0 - they may have to subtract 1 if they count n
from 0 but s from 1.)
Converting back goes like c = n/(H*S), r = n%(H*S), h = r/S, s = r%S.
Under some circumstances the 3D address is used, under some
the 1D. For example, LILO uses the 3D address, but uses the 1D
address if you give the keyword "linear". And fdisk describes
a partition both in 3D and in 1D addresses.
Now look at the conversion between the two.
This conversion uses H and S. So, if someone comes along
and changes the system's idea about H and S, then Bad Things
may happen - the correspondence between 3D and 1D addresses
has changed. Maybe DOS and Linux now disagree about where
the partitions are and your filesystems are corrupted.
So: Never change H and S if you can avoid it.
On the other hand, C does not occur in these equations.
The only place C is used is for the computation of the
total capacity of the disk C*H*S. So, if you know the
total capacity T, and you are careful not to change H and S,
then you have to compute C = T/(H*S).
OK - that is the general theory. See the Large Disk Howto
for more details. Now what is the current point of discussion?
If you ask a current 8+ GB disk about its geometry using the
IDENTIFY command, it will return C/H/S=16383/16/63. These
values are a convention, and just as you recognize 1 Jan 1970
as "no date", so does "16383/16/63" mean "big disk, look at
LBA capacity to see how big". Such large IDE disks did not
exist until recently, since it was unclear how DOS could
use them, but these days 12 GB and 16 GB IDE disks are cheap.
Old kernels did not know about this convention, and didnt believe
the LBA capacity if it differed more than 10% from C*H*S.
Since 2.1.90 and 2.0.35 the Linux kernel knows about this,
and people who do not use translation have no problems with
these big disks.
But most BIOSes allow you to complicate matters by choosing
"LBA" or "Large" or "Extended" or "Translation", in which case
C,H,S will be replaced by the BIOS by C',H',S' such that
C*H*S = C'*H'*S'. If the BIOS does not know about the
abovementioned convention, then it will replace 16383/16/63
by 1023/255/63 (or 1024/255/63 or so).
At present Linux recognizes 16383/16/63 and knows that it is
not for real, and looks at LBA capacity to see how large the
disk is in reality, but the kernel does not recognize such
translated geometries like 1023/255/63.
This leads to the situation where fdisk can only describe
8 GB of a much larger disk in case the BIOS uses some translation.
The solution is very simple. When the kernel has decided on
what the total capacity T of the disk is, and the BIOS has
mentioned its favourite H and S, the kernel must compute
C = T/(H*S).
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/