Page suivante Page précédente Table des matières

14. Résolution des problèmes

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.

14.1 Problème : Linux invente une fausse géométrie pour mon disque.

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.

14.2 Faux problème : Des disques identiques ont des géométries différentes ?

`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'.

14.3 Faux problème : 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.


Page suivante Page précédente Table des matières