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 `linear' if it doesn't get past `LI' when booting. Watch the kernel boot messages, and remember: the more you fiddle with geometries (specifying heads and cylinders to LILO and fdisk and on the kernel command line) the less likely it is that things will work. Roughly speaking, all is fine by default.
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.
`I have two identical 10 GB IBM disks. However, fdisk gives different sizes for them. Look:
# fdisk /dev/hdb
Disk /dev/hdb: 255 heads, 63 sectors, 1232 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 1 1232 9896008+ 83 Linux native
# fdisk /dev/hdd
Disk /dev/hdd: 16 heads, 63 sectors, 19650 cylinders
Units = cylinders of 1008 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hdd1 1 19650 9903568+ 83 Linux native
How come?'
What is happening here? Well, first of all these drives
really are 10gig: hdb has size 255*
63*
1232*
512 = 10133544960,
and hdd has size 16*
63*
19650*
512 = 10141286400, so, nothing
is wrong and the kernel sees both as 10.1 GB.
Why the difference in size? That is because the kernel gets
data for the first two IDE disks from the BIOS, and the BIOS
has remapped hdb to have 255 heads (and 16*
19650/255=1232 cylinders).
The rounding down here costs almost 8 MB.
If you would like to remap hdd in the same way, give the kernel boot parameters `hdd=1232,255,63'.
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:
# sfdisk -s /dev/hda9
4095976
# mke2fs -i 1024 /dev/hda9
mke2fs 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09
...
204798 blocks (5.00%) reserved for the super user
...
# mount /dev/hda9 /somewhere
# df /somewhere
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda9 3574475 13 3369664 0% /mnt
# df -i /somewhere
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda9 4096000 11 4095989 0% /mnt
#
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:
# mke2fs /dev/hda9
# mount /dev/hda9 /somewhere
# df /somewhere
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda9 3958475 13 3753664 0% /mnt
# df -i /somewhere
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda9 1024000 11 1023989 0% /mnt
#
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.