Page suivante Page précédenteTable 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é lba32 s'il ne dépasse pas le stade LI au démarrage. Regardez bien les messages de démarrage du noyau et souvenez-vous que 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), moins cela aura de chances de fonctionner. En gros, les valeurs par défaut sont les bonnes.

Et souvenez-vous : la géométrie des disques durs n'est utilisée nulle part 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, ce peut être un problème de géométrie. Si d'autres systèmes d'exploitation ne comprennent pas la table des partitions, ce 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 : La géométrie de mon disque dur IDE est fausse quand je démarre depuis du SCSI.

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 voie assigner une géométrie appartenant à sda. Cela 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 -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
Comment cela est-il possible ?"

Que se passe-t-il ici ? Eh 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'arrondi 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 fichiers sur le disque, disons avec mke2fs, alors ce système de fichiers 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 d'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 fichiers 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 énormément 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
#
À 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 fichiers peut avoir au plus 1024000 fichiers (plus qu'assez), contre 4096000 (trop) auparavant.

Page suivante Page précédenteTable des matières