Many people think they have problems, while in fact nothing is wrong.
Or, they think that the problems they have are due to disk geometry,
while in fact disk geometry has nothing to do with the matter.
All of the above may have sounded complicated, but disk geometry
handling is extremely easy: do nothing at all, and all is fine;
or perhaps give LILO the keyword
And remember: nowhere in Linux is disk geometry used, so no problem you have while running Linux can be caused by disk geometry. Indeed, disk geometry is used only by LILO and by fdisk. So, if LILO fails to boot the kernel, that may be a geometry problem. If different operating systems do not understand the partition table, that may be a geometry problem. Nothing else. In particular, if mount doesnt seem to work, never worry about disk geometry - the problem is elsewhere.
It is quite possible that a disk gets the wrong geometry. The Linux kernel asks the BIOS about hd0 and hd1 (the BIOS drives numbered 80H and 81H) and assumes that this data is for hda and hdb. But on a system that boots from SCSI, the first two disks may well be SCSI disks, and thus it may happen that the fifth disk, which is the first IDE disk hda, gets assigned a geometry belonging to sda. Such things are easily solved by giving boot parameters `hda=C,H,S' for the appropriate numbers C, H and S, either at boot time or in /etc/lilo.conf.
Since Linux 2.5.51 this BIOS information is not used anymore, and the same problem occurs for all disks. See below.
`I have two identical 10 GB IBM disks. However, fdisk gives different sizes for them. Look:
What is happening here? Well, first of all these drives
really are 10gig: hdb has size 255
If you would like to remap hdd in the same way, give the kernel boot parameters `hdd=1232,255,63'.
On the other hand, if the disk is not shared with DOS or so, it may be better to set hdb to Normal in the BIOS setup, instead of asking for some translation like LBA.
Since Linux 2.5.51, the IDE driver no longer uses BIOS info on the first two disks, and the different treatment of the first two disks has disappeared.
14.3 Problem: 2.4 and 2.6 report different geometries? 2.6 reports the wrong geometry? 2.6 reports no geometry at all?
Since geometry does not exist, it is not surprising that each of 2.0/2.2/2.4/2.6 reports a somewhat different disk geometry.
Some people will maintain that geometry *does* exist, and in that
case do not mean a property of the disk, but mean the values
reported by the BIOS. That is what several other operating systems
will use. Since Linux 2.5.51, the kernel no longer uses the values
reported by the BIOS - it is difficult to match BIOS device numbers
with Linux disk names, maybe data is only available for two disks,
maybe some disks are not present in the BIOS setup, etc.
However, if one needs these values, since Linux 2.6.5 one can set
CONFIG_EDD and mount sysfs, and then find the BIOS data for the
various disks under
This 2.5.51 change caused problems when many people using both Linux
and Windows on the same disk upgraded from 2.4 to 2.6 and used as
partitioning tool the program
fdisk will tell you how many blocks there are on the disk. If you make a filesystem on the disk, say with mke2fs, then this filesystem needs some space for bookkeeping - typically something like 4% of the filesystem size, more if you ask for a lot of inodes during mke2fs. For example:
We have a partition with 4095976 blocks, make an ext2 filesystem on it, mount it somewhere and find that it only has 3574475 blocks - 521501 blocks (12%) was lost to inodes and other bookkeeping. Note that the difference between the total 3574475 and the 3369664 available to the user are the 13 blocks in use plus the 204798 blocks reserved for root. This latter number can be changed by tune2fs. This `-i 1024' is only reasonable for news spools and the like, with lots and lots of small files. The default would be:
Now only 137501 blocks (3.3%) are used for inodes, so that we have 384 MB more than before. (Apparently, each inode takes 128 bytes.) On the other hand, this filesystem can have at most 1024000 files (more than enough), against 4096000 (too much) earlier.
Next Previous Contents