Verder Terug Inhoud

14. Probleem oplossing

Veel mensen denken dat ze problemen hebben, terwijl er in feite niets mis is. Of ze denken dat de problemen die ze hebben, te wijten zijn aan de diskgeometrie, terwijl de diskgeometrie er in feite niets mee heeft te maken. Het kan zijn dat het bovenstaande gecompliceerd klinkt, maar diskgeometrie afhandeling is uiterst eenvoudig: doe in het geheel niets en alles is in orde; of geef LILO wellicht het sleutelwoord `linear' als het bij het booten niet verder komt dan `LI'. Bekijk de kernel bootmeldingen, en denk er aan: hoe meer je met geometries knoeit (het specificeren van heads en cylinders aan LILO en fdisk en op de kernel opdrachtregel) hoe minder waarschijnlijker het is dat het zal werken. Globaal genomen is standaard alles in orde.

En denk eraan: nergens in Linux wordt diskgeometrie gebruikt, dus je kunt tijdens het draaien van Linux geen probleem hebben die door diskgeometrie wordt veroorzaakt. Inderdaad, diskgeometrie wordt alleen door LILO en door fdisk gebruikt. Dus als LILO er niet in slaagt de kernel te booten, kan dat een geometrie probleem zijn. Als andere besturingssystemen de partitietabel niet begrijpen, kan dat een geometrieprobleem zijn. Anders niets. In het bijzonder, als mount niet schijnt te werken, maak je dan nooit zorgen over de diskgeometrie - het probleem ligt ergens anders.

14.1 Probleem: Mijn IDE-disk krijgt de verkeerde geometrie als ik vanaf SCSI boot

Het is heel goed mogelijk dat een disk de verkeerde geometrie krijgt. De Linux kernel ondervraagt de BIOS over hd0 en hd1 (de BIOS drives genummerd 80H en 81H) en gaat ervan uit dat deze data voor hda en hdb is. Maar op een systeem dat vanaf SCSI boot, kunnen de eerste twee disks net zo goed SCSI disks zijn, en kan het dus gebeuren dat de vijfde disk, wat de eerste IDE disk hda is, een geometrie krijgt toegewezen die aan sda toebehoort. Dergelijke zaken worden gemakkelijk opgelost door boot parameters `hda=C,H,S' op te geven voor de bestemde nummers C, H en S, of bij het booten of in /etc/lilo.conf.

14.2 Geen probleem: Identieke disks hebben verschillende geometries?

`Ik heb twee identieke 10 GB IBM disks. Echter, fdisk geeft verschillende groottes voor ze op. Kijk:

# fdisk -l /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 -l /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
Hoe komt dit?'

Wat is hier aan de hand? Als eerste zijn deze drives in werkelijkheid 10gig: hdb heeft een grootte van 255*63*1232*512 = 10133544960, en hdd heeft een grootte van 16*63*19650*512 = 10141286400, dus er is niets mis en de kernel ziet beiden als 10.1 GB. Waarom het verschil in grootte? Dat is omdat de kernel zijn data voor de eerste twee IDE disks vanuit de BIOS krijgt, en de BIOS heeft hdb heringedeeld alsof het 255 heads heeft (en 16*19650/255=1232 cylinders). De afronding naar beneden kost hier bijna 8 MB.

Als je hdd op dezelfde manier zou willen herindelen, geef dan de kernel boot parameters `hdd=1232,255,63' op.

14.3 Geen probleem: fdisk ziet meer ruimte dan df?

fdisk laat je weten hoeveel blokken er op de disk voorkomen. Als je een bestandssysteem op de disk aanmaakt, laten we zeggen met mke2fs, dan heeft dit bestandssysteem wat ruimte nodig voor adminstratie - kenmerkend iets als 4% van de grootte van het bestandssysteem, meer als je vraagt om een boel inodes gedurende mke2fs. Bijvoorbeeld:

# 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 /ergens
# df /ergens
Filesystem         1024-blocks  Used Available Capacity Mounted on
/dev/hda9            3574475      13  3369664      0%   /mnt
# df -i /ergens
Filesystem           Inodes   IUsed   IFree  %IUsed Mounted on
/dev/hda9            4096000      11 4095989     0%  /mnt
#
We hebben een partitie met 4095976 blokken, maken er een ext2 bestandssysteem op aan, mounten het ergens en bemerken dat het slechts 3574475 blokken heeft - 521501 blokken (12%) zijn verloren gegaan aan inodes en andere administratie. Merk op dat het verschil tussen het totaal 3574475 en de 3369664 beschikbaar voor de gebruiker de 13 blokken zijn die in gebruik zijn plus de 204798 blokken die voor root zijn gereserveerd. Dit laatste nummer kan worden gewijzigd door tune2fs. Deze `-i 1024' is alleen redelijk voor news spools en dergelijke, met heel veel kleine bestanden. De standaard zou zijn:
# 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
#
Nu worden er slechts 137501 blokken (3.3%) voor inodes gebruikt, zodat we 384 MB meer dan voorheen hebben. (blijkbaar, neemt iedere inode 128 bytes in beslag.) Aan de andere kant, kunnen er op dit bestandssysteem maximaal 1024000 bestanden voorkomen (meer dan genoeg), tegen 4096000 (te veel) daarvoor.
Verder Terug Inhoud