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

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:42