Beaucoup de personnes pensent qu'elles ont des problèmes, alors qu'en
réalité rien ne cloche. Elles peuvent également penser que leurs problèmes
sont dus à la géométrie du disque, alors que cela n'a rien à voir. Tout ce
que nous avons vu ci-dessus peut vous avoir paru compliqué, mais
maîtriser le domaine de la géométrie des disques durs est très facile :
ne faites rien du tout, et tout ira bien ; ou peut-être faudra-t-il
donner à LILO le mot-clé `linear' s'il ne dépasse pas le stade LI au
démarrage. Regardez bien les messages de démarrage du noyau, et
souvenez-vous qu'au plus vous tripoterez les géométries (en spécifiant le
nombre de têtes et de cylindres à LILO et à fdisk
, et en les passant
comme argument au noyau), au moins cela aura de chances de fonctionner.
En gros, les valeurs par defaut sont les bonnes.
Et souvenez-vous : la géométrie des disques durs n'est utilisée nulle par
dans Linux, donc les problèmes que vous pouvez avoir en vous servant de
Linux ne sont pas dus à ça. En fait, la géométrie des disques durs n'est
utilisée que par LILO et par fdisk
. Donc, si LILO ne parvient pas à charger
le noyau, ça peut être un problème de géométrie. Si d'autres systèmes
d'exploitation ne comprennent pas la table des partitions, ça
peut être un problème de géométrie. Rien d'autre. En particulier, si
mount ne semble pas vouloir fonctionner, ne vous posez jamais de question
sur la géométrie - le problème est ailleurs.
Il est assez possible qu'un disque dur obtienne une mauvaise géométrie. Le noyau de Linux questionne le BIOS au sujet de hd0 et hd1 (les disques du BIOS numérotés 80H et 81H) et suppose que ces données sont pour hda et hdb. Mais, sur un système qui démarre depuis du SCSI, les deux premiers disques peuvent très bien être des disques durs SCSI, et de ce fait il peut arriver que le cinquième disque, qui est hda, c'est-à-dire le premier disque IDE, se voit assigner une géométrie appartenant à sda. Ceci est facilement résolu en donnant, au démarrage ou dans le fichier /etc/lilo.conf, les paramètres pour hda `hda=C,H,S' avec les valeurs appropriées pour C, H et S.
`Je possède deux disques durs IBM identiques de 10 Go. Cependant, fdisk
donne des tailles différentes pour les deux. Voyez :
# 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
Comment cela est-il possible ?
Que se passe-t-il ici ? Bien, avant tout ces disques sont réellement de 10
Giga : hdb a comme taille 255*
63*
1232*
512 = 10133544960, et
hdd a pour taille 16*
63*
19650*
512 = 10141286400, donc tout
va bien, et le noyau voit les deux comme des 10 Go.
Pourquoi y a-t-il cette différence de taille ? C'est parce que le noyau
obtient ses données du BIOS pour les deux premiers disques IDE, et le BIOS
a recartographié hdb pour qu'il ait 255 têtes (et
16*
19650/255=1232 cylindres). L'arondi inférieur coûte ici au
moins 8 Mo.
Si vous voulez recartographier hdd de la même manière, donnez au noyau l'option de démarrage `hdd=1232,255,63'.
fdisk
voit beaucoup plus d'espace que df ?
fdisk
vous donnera le nombre de blocs qu'il y a sur le disque dur. Si vous
avez créé un système de fichier sur le disque, disons avec mke2fs, alors ce
système de fichier a besoin d'un peu de place pour sa comptabilité -
typiquement quelque chose comme 4% de la taille du système de fichier, un
peu plus si vous demandez beaucoup de inodes à mke2fs. Par exemple :
# 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 /quelque/part
# df /quelque/part
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda9 3574475 13 3369664 0% /mnt
# df -i /quelque/part
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda9 4096000 11 4095989 0% /mnt
#
Nous avons une partition de 4095976 blocs, créez sur cette dernière un
système de fichier ext2, montez-la quelque part, et remarquez qu'elle n'a
que 3574475 blocs - 521501 blocs (12%) ont été perdus en inodes et autres
pour de la comptabilité. Remarquez que la différence entre le total de
3574475 blocs et les 3369664 disponibles pour l'utilisateur est égale aux
13 blocs utilisés plus les 204798 blocs réservés à root. Cette dernière valeur
peut être changée à l'aide de tune2fs. Ce `-i 1024' n'est
raisonnable que dans le cadre d'un spoule de forums d'utilisateurs ou quelque
chose du même style, avec énormement de petits fichiers. Par défaut
on mettrait :
# mke2fs /dev/hda9
# mount /dev/hda9 /quelque/part
# df /quelque/part
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda9 3958475 13 3753664 0% /mnt
# df -i /quelque/part
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda9 1024000 11 1023989 0% /mnt
#
A présent, seulement 137501 blocs (3,3%) sont utilisés pour les inodes,
comme cela, nous disposons de 384 Mo de plus qu'avant. (Apparemment, chaque
inode occupe 128 octets.) D'un autre côté, ce système de fichier peut
avoir au plus 1024000 fichiers (plus qu'assez), contre 4096000 (trop)
auparavant.