[email protected]
,[email protected]
Pour obtenir une version toujours � jour, mais en anglais, de ce document reportez-vous � la page www.win.tue.nl.
Supposons que vous ayez un disque dur de plus de 1024 cylindres. Supposons �galement que vous ayez un syst�me d'exploitation qui utilise l'ancienne interface INT13, d'�ntr�e/Sortie sur disques. Dans ce cas, vous avez un probl�me, parce que cette interface utilise un champ de 10 bits pour coder les cylindres sur lesquels sont effectu�es les �ntr�es/Sorties, de telle mani�re que les cylindres 1024 et au-del� sont inaccessibles.
Heureusement, Linux ne se sert pas du BIOS, donc il n'y a pas de probl�me.
Sauf peut-�tre pour deux choses :
(1) Quand vous d�marrez votre syst�me, Linux ne fonctionne pas encore et ne peut donc pas vous pr�server des probl�mes li�s au BIOS. Cela a certaines cons�quences pour LILO et d'autres programmes d'amor�age du m�me acabit.
(2) Il est n�cessaire que tous les syst�mes d'exploitation qui se partagent un
m�me disque dur se mettent d'accord sur la position physique de chaque
partition. En d'autres termes, si vous utilisez Linux et disons, DOS sur un seul
disque dur, alors les deux se doivent d'interpr�ter la table des partitions de
la m�me mani�re. Cela a quelques cons�quences pour le noyau de Linux et pour
fdisk
.
Vous trouverez ci-dessous une description assez pouss�e de tous les d�tails importants. Prenez en compte le fait que j'utilise comme r�f�rence un noyau dans sa version 2.0.8. D'autres versions pourront donc pr�senter quelques diff�rences.
Vous avez un nouveau disque de grande capacit�. Que faire ? Bon, du c�t�
logiciel il faut utiliser fdisk
(ou mieux, cfdisk
), pour cr�er
les partitions, ensuite mke2fs
pour cr�er un syst�me de fichiers et
enfin mount
pour faire le lien entre ce nouveau syst�me de fichiers et
l'arborescence d�j� existante.
Il n'est pas n�cessaire de lire ce HOWTO � partir du moment o�, de nos jours, il
n'y a pas de probl�me avec les disques de grande capacit�. La grande
majorit� des probl�mes constat�s est due au fait que les gens pensent qu'il peut
y avoir un probl�me et installent un gestionnaire de disques durs, ou passent
en mode expert dans fdisk
, ou encore sp�cifient explicitement une
g�om�trie de disque � LILO ou sur la ligne de commande du noyau.
Cependant, les domaines dans lesquels interviennent typiquement les probl�mes sont :
Conseil :
Pour les disques durs SCSI de grande capacit� : Linux les a tr�s t�t support�s. Il n'y a rien � faire.
Pour les disques durs IDE de grande capacit� (au-del� de 8,4 Go) : procurez-vous un noyau stable r�cent (2.0.34 ou plus). Normalement, tout doit se passer correctement, surtout si vous avez eu la sagesse de ne pas dire au BIOS de faire des conversions du type LBA ou assimil�.
Pour des disques durs IDE de capacit� vraiment importante (au-del� de 33,8 Go) : reportez-vous � la section Probl�mes de l'IDE avec des disques durs de 34 Go et plus plus bas dans ce document.
Si LILO reste bloqu� au d�marrage, il faut essayer de sp�cifier
linear
dans le fichier de configuration
/etc/lilo.conf
(et si linear
�tait d�j� pr�sent, essayez
sans). Si vous avez une version r�cente de LILO (21.4 ou mieux), le mot-cl�
lba32
devrait vous permettre de d�marrer de n'importe o� sur le disque.
Cela signifie en fait que la limite des 1024 cylindres a disparue (bien
entendu, LILO est un peu fragile et il peut �tre plus pratique d'utiliser un
gestionnaire de d�marrage diff�rent).
Il y a des probl�mes de g�om�trie qui peuvent �tre r�solus en passant explicitement une g�om�trie au noyau/LILO/fdisk.
Si vous avez une vieille version de fdisk
et qu'il vous met des
messages d'erreur du type
'overlapping partitions' : ignorez-les ou v�rifiez en utilisant cfdisk
que
tout va effectivement bien.
Pour le HPT366, reportez-vous au Linux HPT366 HOWTO.
Si, au moment du d�marrage, le noyau ne peut pas lire la table des partitions, envisagez la possibilit� que UDMA66 ait-�t� s�lectionn� alors que le contr�leur, le c�ble ou bien le disque dur, ne supportent pas ce mode. Dans ce cas, quoi que vous fassiez, vos tentatives de lecture resteront vaines et, tenter de lire la table des partitions est la premi�re chose que fait le noyau. Assurez-vous que UDMA66 n'est pas utilis�.
Si vous pensez que quelque chose cloche dans la taille de votre disque dur,
assurez-vous que vous n'�tes pas en train de confondre
unit�s binaires et d�cimales et sachez que l'espace libre rapport� par
df
pour un disque vide, est inf�rieur de quelques centi�mes � la taille
de la partition, ce � cause d'un en-t�te de gestion.
Si le noyau rapporte deux tailles diff�rentes pour un m�dia amovible, cela veut dire que l'une est donn�e par le m�dia lui-m�me et l'autre par le disque/la disquette. Cette seconde valeur est �gale � z�ro dans le cas o� aucun disque/disquette n'est pr�sent.
Maintenant, si vous pensez qu'il y a tout de m�me des probl�mes, ou simplement si vous �tes curieux, lisez la suite.
Un kilo-octet (Ko) est �gal � 1000 octets (NdT : un octet se dit byte en anglais et est abr�g� avec un 'B' en majuscule. � ne pas confondre avec un bit, qui se dit bit et qui est abr�g� avec un 'b' en minuscule !). Un M�ga-octet (Mo) est �gal � 1000 Ko. Un Giga-octet (Go) est �gal � 1000 Mo. Un T�ra-octet (To) est �gal � 1000 Go. Ceci est la norme dans le Syst�me International (SI).
Cependant, il y a des personnes qui utilisent la conversion 1 Mo=1024000 octets et parlent de disquettes de 1,44 Mo et des personnes qui pensent que 1 Mo=1048576 octets. L�, je me reporte au nouveau standard et j'�cris Ki, Mi, Gi, Ti pour les unit�s binaires, de telle sorte que les disquettes ont une taille de 1440 Kio (1,47 Mo, 1,41 Mio), 1 Mio est �gal � 1048576 octets (1,05 Mo), 1 Gio repr�sente 1073741824 octets (1,07 Go) et 1 Tio vaut 1099511627776 octets (1,1 To).
D'une mani�re assez normale, les constructeurs de disques durs suivent la norme
SI et utilisent des unit�s d�cimales. Cependant, les messages de d�marrage du
noyau Linux (pour les noyau qui ne sont pas tr�s r�cents) et quelques programmes
de type fdisk
utilisent les symboles MB et GB (Mo et Go en fran�ais)
pour les unit�s binaires, ou binaires-d�cimales m�lang�es. Donc, avant
que vous ne pensiez que votre disque est plus petit que ce qu'on vous avait
promis lors de son achat, calculez sa vraie taille en unit�s d�cimales (ou
simplement en octets).
En ce qui concerne la terminologie et les abr�viations des unit�s binaires, Knuth propose une alternative qui est d'utiliser KKo, MMo, GGo, TTo, PPo, EEo, ZZo, YYo et de les d�nommer grand kilo octet, grand m�ga octet, ... grand yota octet. Il �crit : "Remarquez que le fait de doubler la lettre a une connotation � la fois binaire et d'amplitude." C'est une bonne proposition -- grand giga octet sonne mieux que gibi octet. Cependant, pour le sujet qui est le n�tre, la seule chose importante est de mettre l'accent sur le fait qu'un m�ga octet contient pr�cis�ment 1000000 octets et qu'il est n�cessaire d'employer d'autres termes ou d'autres abr�vations si vous voulez d�signer autre chose.
Dans le cadre de ce texte, un secteur a une taille de 512 octets. Cela est
pratiquement toujours vrai, mais certains disques Magn�to-Optiques par exemple,
utilisent une taille de secteur �gale � 2048 octets et toutes les
capacit�s donn�es ci-dessous doivent �tre multipli�es par quatre. (Si vous
utilisez fdisk
sur de tels disques, assurez-vous d'avoir une version
2.9i ou sup�rieure et passez-lui l'option -b 2048
.)
Un disque avec C cylindres, H t�tes (NdT : t�te se dit head en anglais, d'o� l'abr�viation !) et S secteurs par piste poss�de en tout C×H×S secteurs et peut stocker C×H×S×512 octets. Par exemple, si sur un disque dur il est �crit C/H/S=4092/16/63, alors celui-ci a 4092×16×63=4124736 secteurs et peut contenir 4124736×512=2111864832 octets (2,11 Go). Il y a une convention dans l'industrie qui consiste � donner C/H/S=16383/16/63 pour les disques durs de plus de 8,4 Go et donc la taille du disque ne peut plus �tre d�duite des valeurs C/H/S rapport�es par ce dernier.
Si on veut lire ou �crire quelque chose � partir de, ou sur un disque dur, il faut sp�cifier une position sur ce disque, en donnant par exemple un num�ro de secteur ou de bloc. Si le disque dur est de type SCSI, alors ce num�ro de secteur va directement au moteur de commande SCSI et est compris par le disque. Si le disque dur est de type IDE et qu'il utilise le mode LBA, alors il se passe exactement la m�me chose. Mais si le disque dur est vieux, RLL, MFM ou IDE avant l'apparition du LBA, alors l'�lectronique qui lui est attach�e attend un triplet (cylindre, t�te, secteur) pour d�signer l'endroit voulu.
La correspondance entre la num�rotation lin�aire et cette notation tridimensionnelle est la suivante : pour un disque dur avec C cylindres, H t�tes et S secteurs/pistes, la position (c,h,s) en 3D, ou la notation CHS, est la m�me que la position c×H×S+h×S+(s-1) en notation lin�aire ou bien LBA. (Le -1 est d� au fait que traditionnellement les secteurs sont num�rot�s � partir de 1 et non 0, dans cette notation 3D.)
En cons�quence, pour pouvoir utiliser un tr�s vieux disque non-SCSI, il faut conna�tre sa g�om�trie, c'est-�-dire les valeurs de C, H et S. (Si vous n'avez pas d'information � ce sujet, vous pouvez toujours fouiller cette mine : www.thetechpage.com.)
Linux ne se sert pas du BIOS, mais d'autres syst�mes d'exploitation le font. Le
BIOS, qui existait avant le temps du LBA, offre avec INT13 des routines
d'�ntr�e/Sortie disque qui prennent (c,h,s) comme arguments.
(Plus pr�cis�ment : AH
s�lectionne la fonction � ex�cuter,
CH
correspond aux 8 bits de poids faible du num�ro de cylindre,
CL
a dans ses bits 7-6 les deux bits de poids fort de ce m�me num�ro et
dans ses bits 5-0 le num�ro du secteur, DH
est le num�ro de la t�te et
DL
est le num�ro du lecteur (80h ou 81h). Cela explique en partie
l'agencement de la table des partitions.)
Donc, nous obtenons un CHS cod� sur trois octets, avec 10 bits pour le num�ro du cylindre, 8 bits pour le num�ro de t�te et 6 bits pour le num�ro de secteur sur la piste (num�rot� de 1 � 63). Il s'ensuit que le num�ro de cylindre peut prendre des valeurs allant de 0 � 1023 et que le BIOS ne peut pas adresser plus de 1024 cylindres.
Les logiciels DOS et Windows n'ont pas �volu� quand furent introduits les disques IDE avec le support LBA et ont toujours eu besoin du soutien d'une g�om�trie pour g�rer les disques durs, m�me quand cela n'a plus �t� n�cessaire pour effectuer des �ntr�es/Sorties, mais uniquement pour converser avec le BIOS. Cela signifie bien s�r que Linux a besoin du support de la g�om�trie du disque dur quand il est n�cessaire de communiquer avec le BIOS ou avec d'autres syst�mes d'exploitation, m�me sur des disques durs modernes.
Cet �tat de choses a dur� pendant � peu pr�s quatre ans. Ont alors commenc� � appara�tre sur le march� des disques durs qui ne pouvaient plus �tre adress�s avec les fonctions INT13 (� cause du fait que 10+8+6=24 bits pour (c,h,s) ne peuvent pas adresser plus de 8,5 Go) et une nouvelle interface BIOS a �t� cr��e : les d�nomm�es Fonctions INT13 �tendues, o� DS:SI pointe sur un paquet repr�sentant l'adressage du disque sur 16 octets, qui contient un nombre absolu de blocs commen�ant par 8 octets.
Tout doucement, le monde Microsoft semble aller vers une utilisation de ces Fonctions INT13 �tendues. Probablement, dans quelques ann�es, plus aucun syst�me moderne plac� dans un ordinateur moderne n'aura besoin du concept de 'g�om�trie de disque dur'.
Au plus 65536 cylindres (num�rot�s de 0 � 65535), 16 t�tes (num�rot�es de 0 � 15), 255 secteurs par piste (num�rot�s de 1 � 255), pour une capacit� totale maximale de 267386880 secteurs (de 512 octets chacun), ce qui fait 136902082560 octets (137 Go). En 2001, le premier disque dur d'un capacit� sup�rieure � cela est apparu (le Maxtor Diamondmax de 160 Go).
Au plus 1024 cylindres (num�rot�s de 0 � 1023), 256 t�tes (num�rot�es de 0 � 255), 63 secteurs par piste (num�rot�s de 1 � 63) pour une capacit� totale maximale de 8455716864 octets (8,5 Go). De nos jours, cela est une s�rieuse limitation. Cela signifie que DOS ne peut utiliser les actuels disques de grande capacit�.
Si les m�mes valeurs c,h,s sont utilis�es pour les appels aux fonctions Int13 du BIOS et pour les op�rations d'�ntr�es/Sorties du disque dur, alors les deux limitations s'ajoutent et l'on ne peut utiliser au plus que 1024 cylindres, 16 t�tes, 63 secteurs par piste, ce qui donne une capacit� totale maximale de 528482304 octets (528 Mo), l'abominable limite des 504 Mio pour DOS avec un vieux BIOS. Cela a commenc� � poser des probl�mes aux alentours de 1993 et les gens ont eu recours � toutes sortes de bidouillages, aussi bien au niveau mat�riel (LBA), qu'au niveau du micro-code (NdT : le 'firmware') (les conversions du BIOS), ou qu'au niveau logiciel (les gestionnaires de disques durs). Le concept de 'conversion' a �t� invent� (1994) : un BIOS pouvait utiliser une g�om�trie quand il s'adressait au lecteur et une autre g�om�trie, fausse celle-l�, quand il parlait � DOS et faire des conversions de l'une � l'autre.
Quelques vieux BIOS n'utilisent qu'un champ de 12 bits en RAM CMOS pour donner le nombre de cylindres. De ce fait, ce nombre peut �tre au plus �gal � 4095 et l'on ne peut acc�der qu'� 4095×16×63×512=2113413120 octets. Le fait d'avoir un disque dur de plus grande capacit� se traduirait par un plantage au moment du d�marrage. Cela a pour effet de rendre les disques avec une g�om�trie de 4092/16/63 assez populaires. Et encore de nos jours, beaucoup de gros disques durs ont un cavalier qui permet de faire croire qu'ils ont une g�om�trie de 4092/16/63. Vous pouvez �galement jeter un coup d'oeil � la page plus de 2 Go.
Il y avait un bug dans la gestion des BIOS Phoenix 4.03 et 4.04 qui bloquait le syst�me lors de la configuration du CMOS pour des disques durs ayant une capacit� sup�rieure � 3277 Mo. Jetez un oeil � la page plus de 3 Go.
Une conversion simple du BIOS (ECHS=CHS �tendu, parfois appel�e 'Large disk support' ou simplement 'Large') fonctionne en doublant le nombre de t�tes et en divisant par deux le nombre de cylindres montr�s au DOS, de mani�re r�p�t�e, jusqu'� ce que le nombre de cylindres soit au plus �gal � 1024. Maintenant, DOS et Windows 95 ne peuvent pas supporter 256 t�tes de lecture et donc, dans le cas fr�quent o� le disque dit avoir 16 t�tes, cela signifie que cette moulinette ne fonctionne que jusqu'� une taille de 8192×16×63×512=4227858432 octets (avec une fausse g�om�trie de 1024 cylindres, 128 t�tes et 63 secteurs par piste). Remarquez que ECHS ne modifie pas le nombre de secteurs par piste, donc si ce n'est pas 63, la limite sera encore plus basse. Voyez la page plus de 4 Go.
Des BIOS un peu plus malins que les autres �vitent le probl�me pr�c�dent en ajustant d'abord le nombre de t�tes � 15 ('revised ECHS'), de fa�on qu'une fausse g�om�trie comportant 240 t�tes soit obtenue, valable jusqu'� une taille de 1024×240×63×512=7927234560 octets.
En d�finitive, si le BIOS fait tout ce qu'il peut pour r�ussir la conversion et utilise 255 t�tes et 63 secteurs par piste ('assisted LBA' ou simplement 'LBA') il peut atteindre 1024×255×63×512=8422686720 octets, soit l�g�rement moins que la pr�c�dente limite de 8,5 Go, cela parce que les g�om�tries avec 256 t�tes doivent �tre �vit�es. (Cette conversion utilisera pour le nombre de t�tes la premi�re valeur H, prise dans la suite 16, 32, 64, 128, 255, pour laquelle la capacit� totale du disque dur tient dans 1024×H×63×512 et calcule alors le nombre de cylindres C comme �tant �gal � la capacit� totale divis�e par (H×63×512).)
Le prochain obstacle se pr�sente avec une taille de 33,8 Go. Le probl�me est qu'avec les 16 t�tes et les 63 secteurs/piste par d�faut, �a donne un nombre de cylindres sup�rieur � 65535, qui ne rentre pas dans un short. La plupart des BIOS existants ne peuvent pas g�rer de tels disques. (Jetez un oeil, par exemple � Asus upgrades pour une nouvelle image � flasher qui fonctionne.) Les noyaux Linux plus anciens que le 2.2.14/2.3.21 ont besoin d'un correctif. Voyez les probl�mes pos�s par les disques durs IDE de 34 Go et plus ci-dessous.
Comme ceci a d�j� �t� mentionn� ci-dessus, le vieux protocole ATA utilises 16+4+8=28 bits pour donner le num�ro de secteur et de ce fait, ne peut pas adresser plus de 2^28 secteurs. ATA-6 d�crit une extension qui permet d'adresser 2^48 secteurs, soit un million de fois plus. Les noyaux tr�s r�cents incluent un support pour cette extension.
Pour une autre discussion sur ce sujet, vous pouvez consulter la page Breaking the Barriers et pour encore plus de d�tails, IDE Hard Drive Capacity Barriers.
Les disques durs de plus de 8,4 Go sont suppos�s donner leur g�om�trie comme �tant 16383/16/63. Cela signifie en fait que la 'g�om�trie' est obsol�te, et qu'elle ne peut plus servir � calculer la taille totale d'un disque dur.
Quand le syst�me est mis en route, le BIOS lit le secteur 0 (connu sous le nom de MBR : le "Master Boot Record", la donn�e principale d'amor�age) du premier disque dur (ou de la disquette, ou du cd-rom) et saute au code trouv� � cet endroit -- en g�n�ral un chargeur d'amorce. Les petits chargeurs trouv�s � cet endroit n'ont, par principe, pas leur propre gestionnaire de disques durs et utilisent plut�t les services du BIOS. Cela signifie qu'un noyau Linux ne peut �tre charg� que s'il est enti�rement situ� dans les 1024 premiers cylindres du disque, � moins que vous ne poss�diez un BIOS et un chargeur de d'amorce moderne : un BIOS qui supporte les fonctions INT13 �tendues et un chargeur de d'amorce qui sache les utiliser.
Ce probl�me (s'il existe) est r�solu de mani�re tr�s simple : assurez-vous que le noyau (et peut-�tre d'autres fichiers utilis�s pendant la phase de d�marrage, comme les fichiers 'map' de LILO) soit situ� sur une partition qui est comprise toute enti�re dans les 1024 premiers cylindres d'un disque dur auquel le BIOS peut acc�der -- il est probable qu'il s'agisse du premier ou du second disque.
Ainsi, cr�ez une petite partition, disons d'une taille de 10 Mo, de telle
mani�re qu'il y ait de la place pour une poign�e de noyaux, en vous assurant
qu'elle soit contenue enti�rement dans les 1024 premiers cylindres du premier ou
du second disque dur. Montez-le en tant que r�pertoire /boot
;
ainsi, LILO pourra y mettre ses propres fichiers.
La plupart des syst�mes depuis 1998 utilisent un BIOS moderne.
Le principal : si vous utilisez LILO comme chargeur d'amorce, assurez-vous d'avoir un LILO avec une num�ro de version d'au moins 21.4 (LILO peut �tre trouv� � l'adresse suivante : ftp://metalab.unc.edu/pub/Linux/system/boot/lilo/).
Un appel � /sbin/lilo
(le programme qui installe la carte d'amor�age)
permet de stocker une liste d'adresses dans cette carte, pour que LILO (le
chargeur d'amorce) sache � partir d'o� lire l'image du noyau. Par d�faut ces
adresses sont stock�e au format (c,h,s) et un appel INT13 ordinaire est utilis�
au moment du d�marrage.
Quand le fichier de configuration pr�cise lba32
ou linear
, des
adresses lin�aires sont stock�es. Avec l'option lba32
les adresses
lin�aires sont �galement utilis�es au moment du d�marrage si le BIOS supporte
les extensions INT13 �tendues. Avec l'option linear
, ou avec un vieux
BIOS, ces adresses lin�aires sont reconverties sous une forme (c,h,s) et au
moment du d�marrage des appels INT13 ordinaires sont utilis�s.
De ce fait, avec l'option lba32
il n'y a pas de probl�me de g�om�trie
et il n'y a pas de limite � 1024 cylindres. Sans elle, il y a une limite �
1024 cylindres. Qu'en est-il de la g�om�trie ?
Le programme d'amor�age et le BIOS doivent �tre d'accord sur la g�om�trie du
disque dur. /sbin/lilo
demande la g�om�trie au noyau, mais il n'y a
aucune garantie que la g�om�trie du noyau Linux co�ncide avec celle qu'utilise
le BIOS. Donc, la g�om�trie fourni par le noyau est souvent inutile. Dans de
tels cas on peut faciliter la t�che � LILO en lui passant l'option
linear
. L'avantage alors est que, l'id�e qu'� le noyau Linux de la
g�om�trie, n'est plus utilis�e. Le revers de la m�daille est que lilo
ne peut plus vous pr�venir si une partie du noyau est stock�e au-del� de la
limite des 1024 cylindres et vous pouvez vous retrouver avec un syst�me qui
ne d�marre plus.
Avec les versions de LILO ant�rieures � la 2.1 il y a un autre d�savantage : la conversion des adresses effectu�e au d�marrage comporte un bug. Quand c×H est sup�rieur ou �gal � 65536, le calcul provoque un d�passement de capacit�. Pour H sup�rieur � 64 cela donne � c une limite encore plus stricte que le bien connu c<1024 ; par exemple, avec H=255 et un vieux LILO, on doit avoir c<258 (c=cylindre o� r�side l'image du noyau, H=nombre de t�tes du disque).
Tim Williams a �crit : "J'avais ma partition Linux en dessous des 1024 premiers cylindres et �a ne d�marrait quand m�me pas. Au d�but quand je l'ai d�plac�e en dessous de 1 Go, les choses fonctionnaient." Comment cela est-il possible ? En fait, c'�tait un disque dur SCSI avec un contr�leur AHA2940UW qui utilise soit H=64, S=32 (c'est � dire des cylindres de 1 Mio=1,05 Mo), soit H=255, S=63 (c'est � dire des cylindres de 8,2 Mo), en fonction des options du micro-code du disque dur et du BIOS. Il ne fait aucun doute que le BIOS se basait sur le premier groupe de valeurs, c'est pourquoi la limite des 1024 cylindres �tait trouv�e � 1 Gio, alors que Linux utilisait la seconde m�thode et LILO estimait que la limite �tait � 8,4 Go.
Le chargeur d'amorce nuni
ne fait pas appel aux services du BIOS mais
acc�de directement aux unit�s IDE. Donc il est possible de le mettre sur une
disquette ou sur le MBR et de d�marrer de d'importe o� de n'importe quel disque
IDE (pas seulement les deux premiers). Vous pouvez trouver ce chargeur �
ftp://metalab.unc.edu/pub/Linux/system/boot/loaders/
Si vous avez plusieurs syst�mes d'exploitation sur vos disques durs, alors chacun utilise une ou plusieurs partitions. Un d�saccord sur la localisation de ces partitions peut avoir des cons�quences catastrophiques.
Le MBR contient une table des partitions qui d�crit o� se situent les partitions (primaires). Il y a 4 entr�es � la table, pour 4 partitions primaires et chacune ressemble � :
struct partition {
char active; /* 0x80 : on peut demarrer avec ;
0 : on ne peut pas */
char begin[3]; /* CHS pour le premier secteur */
char type;
char end[3]; /* CHS pour le dernier secteur */
int start; /* numero de secteur sur 32 bits (en commencant a 0) */
int length; /* nombre de secteurs sur 32 bits */
};
(avec CHS qui signifie Cylinder/Head/Sector -- Cylindre/T�te/Secteur).
Cette information est redondante : la position de la partition est donn�e �
la fois par les champs begin
et end
cod�s sur 24 bits et
par les champs start
et length
cod�s sur 32 bits.
Linux ne se sert que des champs start
et length
et ne peut de
ce fait que prendre en compte des partitions qui ne comportent pas plus de
2^32 secteurs, c'est-�-dire, des partitions d'au plus 2 Tio. Cette
capacit� est douze fois plus grande que celle des disques durs que l'on peut
trouver de nos jours, alors peut-�tre que cela sera suffisant pour, environ, les
cinq prochaines ann�es. (Donc, les partitions peuvent �tre tr�s grandes, mais il
y a une s�rieuse restriction avec le syst�me de fichiers ext2 quand il est
utilis� sur des machines avec des entiers cod�s sur 32 bits : la
taille maximale d'un fichier est limit�e � 2 Gio.)
DOS utilise les champs begin
et end
et se sert des appels
INT13 du BIOS pour acc�der aux disques durs ; il ne peut g�rer de ce fait
que des disques dont la taille ne d�passe pas 8,4 Go, m�me avec un BIOS qui
fait des conversions. (La taille des partitions ne peut pas exc�der 2,1 Go
� cause des restrictions du syst�me de fichiers FAT16.) La m�me chose est
valable pour Windows 3.11, WfWG et Windows NT 3.*.
Windows 95 int�gre la gestion des interfaces INT13 �tendues et utilise des
types de partition sp�ciaux (c, e, f � la place de b, 6, 5) pour indiquer que
l'on doit acc�der � la partition de cette mani�re. Quand ces types de partition
sont utilis�s, les champs begin
et end
contiennent des
informations factices (1023/255/63).
Windows 95 OSR2 introduit le syst�me de fichier FAT32 (types de partition b ou
c), qui permet d'avoir des partitions d'au plus 2 Tio.
Qu'est-ce que c'est que ce message insens� que vous rapporte fdisk
au
sujet de partitions qui se chevauchent : 'overlapping', quand pourtant tout
est en ordre ? En fait, il y a quelque chose de 'probl�matique' : si
vous voyez les champs begin
et end
de telles partitions, comme
DOS le fait, il y a chevauchement (et cela ne peut pas �tre corrig�, parce que
ces champs ne peuvent pas stocker des num�ros de cylindre plus grands que
1024 : il y aura toujours 'chevauchement' d�s que vous aurez plus de 1024
cylindres). Cependant, si vous voyez les champs start
et
length
, comme les voit Linux et �galement Windows 95 dans le cas
de partitions typ�es c, e ou f, alors tout appara�t comme �tant en ordre.
Donc, ne tenez pas compte de ces avertissements quand cfdisk
ne se
plaint pas et que vous avez un disque dur avec uniquement Linux dessus. Soyez
prudents quand le disque dur est partag� avec DOS. Servez-vous des commandes
cfdisk -Ps /dev/hdx
et cfdisk -Pt /dev/hdx
pour voir la table
des partitions du disque /dev/hdx
.
Un nombre important de vieux IBM PS/2 utilisent des disques durs avec une carte des d�faillances �crite � la fin du disque (le bit 0x20 dans le mot de controle de la table de param�trage du disque est positionn�). De ce fait, FDISK n'utilisera pas le dernier cylindre. Pour se pr�munir d'�ventuel probl�me le BIOS donne souvent un taille inf�rieure d'un cylindre par rapport celle r�elle du disque, ce qui peut faire en tout, deux cylindres de perdus. Les disques r�cents ont plusieurs fonctions permettant de donner leur taille qui, en interne, s'apellent les unes les autres. Quand les deux retirent 1 pour ce cylindre r�serv� et quand FDISK le fait aussi, alors trois cylindres peuvent �tre perdus. De nos jours tout ceci n'a plus de sens mais peut fournir une explication quand on utilise diff�rents utilitaires qui donnent des valeurs diff�rentes pour la taille du disque dur.
La croyance populaire racconte que les partitions doivent commencer et finir aux fronti�res des cylindres.
Puisque la g�om�trie des disques est quelque chose qui n'a pas de r�elle existence, des syst�mes d'exploitation diff�rents inventeront des g�om�tries diff�rentes pour le m�me disque. On voit souvent un syst�me d'exploitation utiliser une g�om�trie apr�s conversion de */255/63 et un autre utiliser une g�om�trie avant conversion de */16/63. Du coup, il devrait �tre impossible d'aligner les partitions sur les limites des cylilndres, si l'on se fie � l'id�e que chaque syst�me d'exploitation a de la g�om�trie du disque. De plus, le fait d'activer ou non le BIOS d'une carte SCSI peut changer la fausse g�om�trie des disques SCSI connect�s.
Par chance, pour Linux les alignements ne sont pas n�cessaires (sauf pour quelques logiciels d'installation boiteux qui aiment bien �tre s�r que tout est d'aplomb ; ce qui peut emp�cher d'installer une RedHat 7.1 sur un disque aux partitions non align�es, DiskDruid n'�tant pas content).
Des personnes rapportent qu'il est facile de cr�er des partitions non align�es sous Windows NT, sans qu'il n'y ait de probl�me apparent.
MSDOS 6.22 par contre, n�cessite un alignement. Les secteurs sur partitions �tendues qui ne sont pas sur la fronti�re d'un cylindre son ignor�es par son FDISK. Le syst�me lui-m�me se satisfait de n'importe quel alignement mais interpr�te les adresses de d�but relatives, comme si elles �taient relatives � une adresse align�e. L'adresse de d�part d'une partition logique est donn�e relativement, non pas � l'adresses de la partition �tendue qui la d�crit, mais au d�but du cylindre qui contient ce secteur (il n'est donc pas �tonnant que, m�me PartitionMagic, n�cessite un alignement).
Quelle est la d�finition de l'alignement ?
FDISK de MSDOS 6.22 se comportera comme suit :
1. Si le premier secteur d'un cylindre est un secteur de table de partition,
alors le reste de la piste sera inutilis� et la partition commencera � la
prochaine piste. Ceci s'applique au secteur 0 (le MBR) et aux secteurs de
table de partition pr�c�dant les partitions logiques.
2. Sinon la partition commence sur le premier secteur du cylindre. De plus, les
partitions �tendues commencent sur une fronti�re de cylindre. La page de manuel
de cfdisk
explique que les vieilles versions de DOS n'alignaient pas
les partitions.
L'utilisation de partitions de type 85 pour les partitions �tendues les rend invisible � DOS, ce qui assure que seul Linux pourra regarder ce qui s'y trouve.
Une petite apart� : sur une Sparc, la partition d'amor�age doit commencer sur une fronti�re de cylindre (mais rien n'est requis pour la fin).
La g�om�trie des disques durs (avec t�tes, cylindres et pistes) est une notion qui date de l'�ge de MFM et RLL. En ces temps l� cela correspondait � une r�alit� physique. Aujourd'hui, avec l'IDE ou le SCSI, plus personne n'est int�ress� par les 'v�ritables' valeurs de la g�om�trie d'un disque dur. En effet, le nombre de secteurs par piste est variable -- il y en a plus pour les pistes proches du bord ext�rieur du disque -- donc il n'y a pas de 'bon' nombre de secteurs par piste. Pratiquement � l'oppos� : la commande IDE, INITIALIZE DRIVE PARAMETERS (91h) est utilis�e pour renseigner le disque dur sur le nombre de t�tes et de secteurs par piste qu'il est sens� avoir � ce moment pr�cis. Il est assez normal de voir un gros disque dur r�cent qui n'a que 2 t�tes, rapporter qu'il en a 15 ou 16 au BIOS, pendant que le BIOS peut � son tour dire au logiciel qui va s'en servir qu'il en a 255.
Pour l'utilisateur, le mieux est de voir le disque dur comme un tableau lin�aire de secteurs num�rot�s 0, 1, ... et de laisser le micro-code trouver o�, sur le disque dur, est situ� tel ou tel secteur. Cette num�rotation lin�aire est appel�e LBA.
Donc, � pr�sent, la vision conceptuelle est la suivante : DOS, ou quel que soit le programme d'amor�age, converse avec le BIOS en se servant de la notation (c,h,s). Le BIOS convertit (c,h,s) en notation LBA en utilisant la g�om�trie factice dont l'utilisateur se sert. Si le disque dur accepte le LBA, alors cette valeur est utilis�e pour les �ntr�es/Sorties sur le disque. Autrement, elle est � nouveau convertie en (c',h',s') en utilisant la g�om�trie dont le disque se sert cette fois-l� et qui est utilis�e pour les �ntr�es/Sorties.
Remarquez qu'il y a une l�g�re confusion dans l'utilisation de l'expression 'LBA' : en tant que terme d�crivant les possibilit�s d'un disque dur, cela signifie 'Linear Block Adressing' -- Adressage de blocs de mani�re lin�aire -- (par opposition � un adressage CHS). En tant que terme de configuration du BIOS, il d�crit la m�thode de conversion parfois appel�e 'Assisted LBA' -- voir plus haut : La limite des 8,4 Go.
Un comportement � peu pr�s identique appara�t quand le micro-code ne parle pas le LBA, mais que le BIOS conna�t la conversion. (Dans la configuration il est souvent mentionn� 'Large'.) Donc, le BIOS va pr�senter une g�om�trie (C,H,S) au syst�me d'exploitation et va utiliser (C',H',S') quand il parlera au contr�leur du disque dur. Habituellement, S=S', C=C'/N et H = H'×N, o� N est la plus petite puissance de deux qui garantisse C' <= 1024 (ainsi un minimum d'espace disque est perdu au moment de l'arrondi dans C'=C/N). Encore une fois, cela permet un acc�s � 8,4 Go maximum (7,8 Gio).
(La troisi�me option de configuration est 'Normal', pour laquelle aucune conversion n'est effectu�e.)
Si un BIOS ne conna�t pas 'Large' ou 'LBA', alors il existe quelque part une solution logicielle. Les gestionnaires de disques durs comme OnTrack ou EZ-Drive remplacent les routines de gestion de disque du BIOS par les leurs. Cela est souvent r�alis� en faisant r�sider le code du gestionnaire de disque dans le MBR et les secteurs suivants (OnTrack nomme ce code DDO : Dynamic Drive Overlay - recouvrement dynamique de disque), comme �a, il est charg� avant n'importe quel autre syst�me d'exploitation. C'est pourquoi on peut avoir des probl�mes en d�marrant depuis une disquette quand un gestionnaire de disque dur a �t� install�.
Le r�sultat est plus ou moins le m�me avec un BIOS qui fait des conversions - mais particuli�rement, c'est quand on utilise plusieurs syst�mes d'exploitation sur le m�me disque dur que ces gestionnaires peuvent poser beaucoup de probl�mes.
Depuis sa version 1.3.14, Linux supporte le gestionnaire de disque dur OnTrack. EZ-Drive quant � lui est support� depuis la version 1.3.29. Quelques d�tails suppl�mentaires sont donn�s dans ce qui suit.
Si le noyau de Linux d�tecte la pr�sence d'un gestionnaire de disque sur un
disque dur IDE, il va essayer de recartographier le disque de la m�me
mani�re que l'aurait fait le gestionnaire de disque, comme �a Linux voit le
m�me partitionnement pour, par exemple, DOS avec OnTrack ou EZ-Drive.
Cependant, AUCUNE recartographie n'est effectu�e quand une g�om�trie a �t�
pass�e en ligne de commande -- donc une option de la ligne de commande comme
'hd=
cyls,
t�tes,
secs' peut tr�s bien briser
la compatibilit� avec un gestionnaire de disque.
Si vous �tes touch� par ce probl�me et que vous connaissez quelqu'un qui peut
compiler pour vous un nouveau noyau, trouvez le fichier linux/drivers/block/ide.c
et supprimez, dans la routine ide_xlate_1024()
, le test
if (drive->forced_geom) { ...; return 0; }
.
La nouvelle cartographie est obtenue en essayant les valeurs 4, 8, 16, 32, 64, 128, 255 pour le nombre de t�tes (H×C reste constant) jusqu'� ce que C <= 1024 ou que H=255.
Ci-dessous les d�tails -- les titres des sous-sections sont les messages qui apparaissent dans les diff�rents messages de d�marrage. Ici et partout ailleurs dans ce texte, les types des partitions sont donn�s en hexad�cimal.
EZ-Drive est d�tect� par le fait que le type de la premi�re partition primaire
est 55. La g�om�trie est recartographi�e comme d�crit ci-dessus et la table
des partitions du secteur 0 est supprim�e -- � la place, la table des
partitions est celle lue sur le secteur 1. Le nombre de blocs du disque n'est
pas chang�, mais les �critures sur le secteur 0 sont redirig�es vers le
secteur 1. Ce comportement peut �tre modifi� en recompilant le noyau
avec #define FAKE_FDISK_FOR_EZDRIVE 0
dans ide.c
.
OnTrack DiskManager (sur le premier disque dur) est d�tect� gr�ce au type 54 de la premi�re partition primaire. La g�om�trie est recartographi�e comme d�crit ci-dessus et la totalit� du disque est d�cal�e de 63 secteurs (comme �a, l'ancien secteur 63 devient le num�ro 0). Ensuite un nouveau MBR (avec une table des partitions) est lu depuis le nouveau secteur 0. Bien s�r ce d�calage a pour but de lib�rer de la place pour le DD0 -- c'est pourquoi il n'y a pas de d�calage sur les autres disques durs.
OnTrack DiskManager (sur les autres disques durs) est d�tect� gr�ce au type 51 ou 53 de la premi�re partition primaire. La g�om�trie est recartographi�e comme d�crit ci-dessus.
Une version plus ancienne de OnTrack DiskManager n'est pas d�tect�e
gr�ce au type de partition, mais par signature. (Un test est effectu�
pour savoir si la valeur de d�calage trouv�e dans les octets 2 et 3 du MBR
n'est pas sup�rieure � 430 et si le short
trouv� � cette valeur de
d�calage est �gal � 0x55AA et qu'il est suivi par un octet impair.) Une fois
encore, la g�om�trie est recartographi�e comme d�crit ci-dessus.
Finalement, il y a un test qui tente de d�duire une conversion � partir des
valeurs start
et end
de la partition primaire : si n'importe quelle
partition a comme secteurs de d�but et de fin respectivement 1 et 63 et
comme dernier num�ro de t�te 31, 63, 127 ou 254, alors, � partir du
moment o� il est habituel de terminer des partitions sur une limite de
secteur et qui plus est depuis que l'interface IDE utilise au plus 16
t�tes, il est suppos� qu'une conversion du BIOS est active et la
g�om�trie est recartographi�e pour utiliser respectivement 32, 64, 128 ou 255
t�tes.
Cependant, le disque n'est pas recartographi� quand la vision actuelle de la
g�om�trie a d�j� 63 secteurs par piste et au moins autant de t�tes (cela
signifie sans doute qu'il a d�j� �t� recartographi�).
Quand Linux d�tecte le gestionnaire de disque Ontrack Disk Manager il
d�cale tous les acc�s disques de 63 secteurs. De la m�me mani�re, si Linux
d�tecte EZ-Drive, tous les acc�s au secteur 0 seront d�cal�s au secteur 1.
Cela signifie qu'il peut s'av�rer difficile de se d�barasse de ces gestionnaires
de disque. La plupart de ces gestionnaires ont une option de d�sinstallation,
mais si vous avez besoin de supprimer un gestionnaire de disque, une approche
peut �tre de donner explicitement une g�om�trie de disque sur la ligne de
commande. De ce fait Linux saute la routine ide_xlate_1024()
et il est
du coup possible de supprimer la table des partitions ainsi que le gestionnaire
de disque (rendant l'acc�s � toutes les donn�es impossible) avec la commande
dd if=/dev/zero of=/dev/hdx bs=512 count=1
Les d�tails d�pendent du num�ro de version mineur du noyau.
Les noyaux r�cents (depuis le 2.3.21) reconanissen les param�tres de d�marrage
tels que hda=remap
et hdb=noremap
. Il est alors possible de
conserver ou d'�viter le d�calage d� � EZD sans se soucier de ce qui est dans la
table des partitions. Le param�tre de d�marrage hdX=noremap
permet
�galement d'�viter le d�calage d� au gestionnaire
Ontrack Disk Manager.
Qu'est-ce que tout cela signifie ? Pour les utilisateurs de Linux seulement
une chose : qu'ils doivent s'assurer que LILO et fdisk
utilisent
la bonne g�om�trie, o� 'bonne' pour fdisk
est d�finie comme la
g�om�trie utilis�e par les autres syst�mes d'exploitation sur le m�me disque
dur et pour LILO comme la g�om�trie qui va permettre des �changes valides avec
le BIOS au moment du d�marrage (en g�n�ral les deux vont de pair).
Comment fdisk
conna�t-il la g�om�trie ?
Il demande au noyau en utilisant l'ioctl HDIO_GETGEO
.
Mais l'utilisateur peut passer outre cela en pr�cisant la g�om�trie de mani�re
interactive, ou sur la ligne de commande.
Comment LILO conna�t-il la g�om�trie ?
Il demande au noyau en utilisant l'ioctl HDIO_GETGEO
.
Mais l'utilisateur peut passer outre cela en utilisant l'option 'disk=
'
dans le fichier /etc/lilo.conf
(voyez la page de manuel lilo.conf(5)).
On peut �galement passer l'option linear
� LILO, il va alors stocker
des adresses LBA � la place des CHS dans son fichier 'map' et retrouvera la
g�om�trie � utiliser au moment du d�marrage (en utilisant la fonction 8 de INT13
pour conna�tre la g�om�trie du disque dur).
Comment le noyau sait-il r�pondre ?
Eh bien, en tout premier lieu, l'utilisateur doit avoir sp�cifi� de mani�re
explicite, soit � la main soit par l'interm�diaire du chargeur d'amorce, la
g�om�trie avec la commande en ligne du noyau
'hda=
cyls,
t�tes,
secs'
(voyez la page de manuel bootparam(7)).
Par exemple, vous pouvez demander � LILO de fournir une telle option en ajoutant
une ligne
'append="hda=
cyls,
t�tes,
secs"
'
dans le fichier /etc/lilo.conf
(voyez la page de manuel de
lilo.conf(5)).
Sinon, le noyau devra deviner, probablement en se servant des valeurs obtenues �
partir du BIOS ou du mat�riel lui-m�me.
Il est possible (depuis Linux 2.1.79) de changer l'id�e qu'a le noyau de la
g�om�trie en utilisant le syst�me de fichiers /proc
.
Par exemple :
# sfdisk -g /dev/hdc
/dev/hdc: 4441 cylinders, 255 heads, 63 sectors/track
# cd /proc/ide/ide1/hdc
# echo bios_cyl:17418 bios_head:128 bios_sect:32 > settings
# sfdisk -g /dev/hdc
/dev/hdc: 17418 cylinders, 128 heads, 32 sectors/track
#
Ceci est particuli�rement utile si vous avez besoin d'un nombre tel de
param�tres sur la ligne de commande, que LILO est d�pass� (ce qui n'est pas
difficile � accomplir).
Comment le BIOS conna�t-il la g�om�trie ? L'utilisateur peut l'avoir donn�e dans la configuration du CMOS. Peut-�tre aussi que la g�om�trie est lue depuis le disque et convertie comme pr�cis� dans la configuration. Dans le cas de disques SCSI, o� il n'y a pas de g�om�trie, celle que le BIOS doit inventer peut �galement �tre pr�cis� via des cavaliers ou des param�tres de configuration (par exemple, les contr�leurs Adaptec ont la possibilit� de choisir entre les valeur habituelles H=64, S=32 et les 'conversions �tendues' H=255, S=63). Parfois, le BIOS lit la table des partitions pour savoir quelle �tait la g�om�trie du disque au moment du dernier partitionnement. -- ceci implique l'hypoth�se qu'une table des partitions valide est pr�sente quand il y a une signature 55aa. Ceci est plut�t positif puisque il est alors possible de d�placer les disques de machine en machine. Mais le fait que le comportement du BIOS d�pende du contenu du disque peut �galement �tre la source d'�tranges probl�mes. Par exemple, il a �t� rapport� qu'un disque de 2,5 Go �tait reconnu comme ayant une capacit� de 528 Mo � cause du BIOS qui lisait la table des partitions et d�duisait qu'il pouvait utiliser des valeurs CHS non converties. Un autre effet de ce comportement peut �tre lu dans ce rapport : des disques non partitionn�s �taient plus lents que des disques partitionn�s, ceci � cause du BIOS qui testait des modes 32 bits en lisant le MBR et en voyant qu'il poss�dait effectivement une signature 55aa.
Comment le disque conna�t-il la g�om�trie ? En fait, le fabricant invente une g�om�trie qui, � un facteur pr�s, donne la bonne capacit�. De nombreux disques ont des cavaliers qui permettent de modifier la g�om�trie qu'ils donnent. Ceci permet d'�viter les bugs des BIOS. Par exemple, tous les disques IBM permettent � l'utilisateur de choisir entre 15 et 16 t�tes et de nombreux fabricants ajoutent des cavaliers pour permettre de faire croire que le disque est plus petit que 2,1 Go ou 33,8 Go. Vous pouvez �galement lire la partie sur les cavaliers plus bas. Parfois, certains utilitaires permettent de changer le micro-code du disque dur.
Parfois il est utile de forcer une certaine g�om�trie en ajoutant
'hda=
cyls,
t�tes,
secs' � la
ligne de commande du noyau. On voudra pratiquement toujours secs=63 et
le but recherch� en ajoutant cela est de sp�cifier t�tes. (Des valeurs
raisonnables de nos jours sont t�tes=16 et t�tes=255.) Que
devra-t-on mettre pour cyls ? Pr�cis�ment le nombre qui donnera la
bonne capacit� totale de C*H*S secteurs.
Par exemple, pour un disque dur avec 71346240 secteurs (36529274880 octets) on
calculera C comme �tant 71346240/(255*63)=4441 (par exemple en utilisant le
programme bc
) et on donnera le param�tre de d�marrage
hdc=4441,255,63
.
Comment conna�t-on la capacit� totale exacte ? Par exemple,
# hdparm -g /dev/hdc | grep sectors
geometry = 4441/255/63, sectors = 71346240, start = 0
# hdparm -i /dev/hdc | grep LBAsects
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=71346240
donne deux mani�res de trouver le nombre total de secteurs 71346240.
Les noyaux r�cent donnent �galement la taille pr�cise dans les messages de
d�mararge :
# dmesg | grep hde
hde: Maxtor 93652U8, ATA DISK drive
hde: 71346240 sectors (36529 MB) w/2048KiB Cache, CHS=70780/16/63
hde: hde1 hde2 hde3 < hde5 > hde4
hde2: <bsd: hde6 hde7 hde8 hde9 >
Les noyaux plus anciens donnent simplement les Mo et CHS. En g�n�ral la valeur
CHS et arrondie � l'entier inf�rieur, ce qui, pour la sortie ci-dessus, nous
donnerait au moins 70780×16×63=71346240 secteurs. Dans cet
exemple, il se trouve que ce sont les valeurs pr�cises. La valeur en Mo peut
�tre arrondie au lieu d'�tre tronqu�e et peut, dans les vieux noyaux, �tre en
unit�s 'binaire' (Mio) plut�t que d�cimale. Remarquez la correspondance entre la
taille en Mo donn�e par le noyau et le num�ro de mod�le du Maxtor.
�galement, dans le cas des disques SCSI, le nombre pr�cis de secteurs est donn� dans les
message de d�marrage du noyau :
SCSI device sda: 17755792 512-byte hdwr sectors (9091 MB)
Le gestionnaire IDE a cinq sources d'information concernant la g�om�trie. La premi�re (G_user) est celle donn�e par l'utilisateur sur la ligne de commande. La deuxi�me (G_bios) est la 'BIOS Fixed Disk Parameter Table' -- table des param�tres de disque fixe du BIOS -- (pour le premier et second disque dur seulement) qui est lue au d�marrage du syst�me, avant le passage au mode 32 bits. Les troisi�me (G_phys) et quatri�me (G_log) sont donn�es par le contr�leur IDE en r�ponse � la commande IDENTIFY -- ce sont les g�om�tries 'physique' et 'logique du moment'.
D'un autre c�t�, le gestionnaire a besoin de deux valeurs pour la
g�om�trie : d'abord G_fdisk, donn�e par un ioctl HDIO_GETGEO
et
ensuite G_used, qui est effectivement utilis�e pour les �ntr�es/Sorties. G_fdisk
et G_used sont toutes deux initialis�es avec la valeur de G_user si elle est
fournie, avec G_bios quand le CMOS dit que cette valeur est pr�sente et avec
G_phys autrement. Si G_log semble vraisemblable, alors G_used est positionn�e �
cette valeur. Sinon, si G_used n'est pas vraisemblable et que G_phys semble
l'�tre, alors G_used prend la valeur de G_phys. Ici, 'vraisemblable' signifie
que le nombre de t�tes est compris dans l'intervalle 1-16.
En d'autres termes : la ligne de commande prend le pas sur le BIOS et va
d�terminer ce que va voir fdisk
, mais si elle donne une g�om�trie
convertie (avec plus de 16 t�tes), alors pour les �ntr�es/Sorties qu'effectuera
le noyau elle sera elle-m�me remplac�e par les valeurs que fournira la commande
IDENTIFY.
Remarquez que G_bios est assez peu fiable : pour des syst�mes qui d�marrent depuis un p�riph�rique SCSI, les premier et second disques durs peuvent tr�s bien �tre SCSI ; et la g�om�trie que le BIOS aura donn� pour sda sera utilis�e par le noyau pour hda. Du reste, les disques durs qui ne sont pas d�clar�s dans la configuration du BIOS ne sont pas vus par ce dernier. Cela signifie que, par exemple, dans un syst�me uniquement IDE o� hdb n'est pas d�clar� dans la configuration, les g�om�tries rapport�es par le BIOS pour les premier et second disques vont �tre appliqu�es � hda et hdc.
Quand on envoie la commande IDENTIF DRIVE (0xec) � un disque dur IDE, il retournera 256 mots d'information contenant de nombreux d�tails techniques. Concentrons nous uniquement sur ce qui joue une r�le pour la g�om�trie. Les mots sont num�rot�s de 0 � 255.
Nous trouvons ici trois informations : DefaultCHS (mots 1,3,6), CurrentCHS (mots 54-58) et LBAcapacity (mots 60-61).
Description | Exemple | |
0 | Champ de bits : bit 6 : disque fixe, bit 7 : media amovible | 0x0040 |
1 | Nombre par d�faut de cylindres | 16383 |
3 | Nombre par d�faut de t�tes | 16 |
6 | Nombre par d�fautl de secteurs par piste | 63 |
10-19 | Num�ro de s�rie (en ASCII) | K8033FEC |
23-26 | R�vision du micro-code (en ASCII) | DA620CQ0 |
27-46 | Nom du mod�le (en ASCII) | Maxtor 54098U8 |
49 | Champ de bits : bit 9 : supporte le LBA | 0x2f00 |
53 | Champ de bits : bit 0 : les mots 54-58 sont valides | 0x0007 |
54 | Nombre actuel de cylindres | 16383 |
55 | Nombre actuel t�tes | 16 |
56 | Nombre actuel de secteurs par piste | 63 |
57-58 | Nombre total actuel de secteurs | 16514064 |
60-61 | Nombre par d�faut de secteurs | 80041248 |
255 | Checksum et signature (0xa5) | 0xf9a5 |
Les cha�nes ASCII sont compos�es de mots contenant chacun deux caract�res, le premier �tant l'octet de poids fort et le second l'octet de poids faible. Les valeurs 32-bits sont donn�es avec le mot de poids faible d'abord. Les mots 54-58 sont positionn�s � l'aide de la commande INITIALIZE DRIVE PARAMETERS (0x91). Ils n'ont un sens que quand CHS est utilis�, mais peuvent aider � trouver la taille r�elle du disque dans le cas o� celui-ci donne les valeurs 4092/16/63 � DefaultCHS (dans le but d'�viter les probl�mes de BIOS).
Parfois, quand un cavalier force un disque � donner une fausse valeur pour LBAcapacity (le plus souvent une valeur de 66055248 secteurs pour pouvoir rester en dessous de la valeur limite de 33,8 Go), il faut disposer d'une quatri�me information pour trouver la taille r�elle du disque : le r�sultat de la commande READ NATIVE MAX ADDRESS (0xf8).
La situation pour le SCSI est l�g�rement diff�rente, puisque les commandes
SCSI utilisent d�j� les num�ros de blocks logiques, donc une 'g�om�trie' est
compl�tement hors de propos pour les v�ritables �ntr�es/Sorties.
Cependant, le format de la table des partitions est toujours le m�me,
donc fdisk
ne fait pas la diff�rence entre des disques IDE et SCSI.
Comme on peut le voir � partir de la description d�taill�e ci-dessus, chaque
gestionnaire de disques s'invente une g�om�trie diff�rente. Un gros foutoir
en fait.
Si vous n'utilisez pas DOS ou un �quivalent, alors �vitez toute configuration qui met en jeu des conversions �tendues et utilisez simplement 64 t�tes, 32 secteurs par piste (cela a pour effet de donner une valeur tout � fait sympathique et commode de 1 Mio par cylindre), si possible, comme �a il n'y aura pas de probl�me quand vous d�placerez le disque dur d'un contr�leur � un autre. Certains gestionnaires de disque SCSI (aha152x, pas16, ppa, qlogicfas, qlogicisp) sont si sensibles au sujet de la compatibilit� avec le DOS qu'ils ne permettront pas � un syst�me uniquement Linux d'utiliser plus de 8 Gio. C'est un bug.
Quelle est la vraie g�om�trie ?
La r�ponse la plus facile est qu'elle n'existe pas.
Et si elle existait, vous ne voudriez pas la conna�tre et � coup s�r
JAMAIS, AU GRAND JAMAIS ne devrez en dire quoi que ce soit � fdisk
ou �
LILO ou au noyau.
C'est uniquement une histoire entre le contr�leur SCSI et le disque dur.
Laissez-moi le redire : seules les personnes stupides donnent �
fdisk
, � LILO ou au noyau la v�ritable g�om�trie d'un disque SCSI.
Mais si vous �tes curieux et que vous insistez, vous devez demander au disque
dur lui-m�me. Il y a l'importante commande READ CAPACITY qui donnera la
capacit� compl�te du disque dur et il y a la commande MODE SENSE, qui, dans
la Rigid Disk Drive Geometry Page (page 04) donne le nombre de cylindres et
de t�tes (c'est une donn�e qui ne peut pas �tre chang�e) et dans
la Format Page (page 03) donne le nombre d'octets par secteur et de secteurs
par piste. Ce dernier nombre est typiquement d�pendant du rang et le nombre
de secteurs par piste varie -- les pistes ext�rieures ont plus de secteurs que
les pistes int�rieures. Le programme Linux scsiinfo
donnera cette
information. Il y a de nombreux d�tails et complications et il est clair que
personne (probablement m�me pas le syst�me d'exploitation) ne d�sire
utiliser cette information. Du reste, tant que nous ne nous int�ressons qu'�
fdisk
et � LILO, on a typiquement des r�ponses du style
C/H/S=4476/27/171 -- valeurs qui ne peuvent pas �tre utilis�es par
fdisk
parce que la table des partitions ne r�serve que 10,8 et 6 bits pour
respectivement C/H/S.
Mais alors, d'o� le HDIO_GETGEO
du noyau tire-t-il ses
informations ?
Eh bien, soit du contr�leur SCSI, soit en faisant une supposition �clair�e.
Certains gestionnaires de disque semblent croire que nous voulons
conna�tre la 'r�alit�', mais bien s�r nous ne voulons savoir que ce que
FDISK de DOS ou de OS/2 (ou AFDISK de Adaptec, etc.) utiliseront.
Remarquez que le fdisk
de linux a besoin des nombres H et S de
t�tes et de secteurs par piste pour convertir les nombres de secteurs
LBA en adresses c/h/s, mais le nombre de cylindres C ne joue aucun
r�le. Quelques gestionnaires de disque utilisent (C,H,S)=(1023,255,63) pour
signaler que la capacit� du disque dur est d'au moins 1023×255×63
secteurs. Ce n'est pas de chance, puisqu'ils ne r�v�lent pas la vraie taille et
limiteront les utilisateurs de la plupart des versions de fdisk
�
n'avoir acc�s qu'� environ 8 Gio de leur disque -- une s�rieuse
limitation de nos jours.
Dans le texte ci-dessous, M repr�sente la capacit� totale du disque dur et C, H, S, le nombres de cylindres, de t�tes et de secteurs par piste. Il suffit de donner H, S si l'on voit C comme �tant d�fini par M/(H×S).
Par d�faut, H=64 et S=32.
H=64, S=32.
H=64, S=32 � moins que C ne soit sup�rieur � 1024, auquel cas H=255, S=63,
C=min(1023, M/(H×S)).
(Ainsi C est tronqu� et H×S×C n'est pas une approximation de la
capacit� M du disque dur. Cela va d�router la plupart des versions de
fdisk
.) Le code de ppa.c
utilise M+1 � la place de M et dit qu'�
cause d'un bug dans sd.c
, M est plus petit de 1.
H=64 et S=32 � moins que C ne soit sup�rieur � 1024 ou que, encore mieux, l'option du BIOS '> 1 GB' ait �t� activ�e, auquel cas H=255 et S=63.
Demande au contr�leur lequel des deux sch�mas de conversion est utilis� et se sert soit de H=255, S=63, soit de H=64, S=32. Dans le dernier cas, il y a un message au d�marrage qui dit "aha1542.c: Using extended bios translation" ("aha1542.c: Utilisation du mode de conversion �tendu du bios")
H=64 et S=32 � moins que C ne soit sup�rieur � 1024 ou que, mieux encore,
le param�tre de d�marrage "extended" ait �t� pass�, ou que le bit 'extended'
ait �t� positionn� dans la SEEPROM ou dans le BIOS, auquel cas H=255, S=63.
Dans Linux 2.0.36 ce mode de conversion �tendu devrait toujours �tre
automatiquement utilis� si il n'y a pas de SEEPROM, mais dans Linux 2.2.6,
si le m�me cas se pr�sente, le mode de conversion �tendu est utilis�
seulement si l'utilisateur le demande au travers du param�tre de d�marrage (de
ce fait, quand une SEEPROM est trouv�e, le param�tre de d�marrage est ignor�).
Cela signifie qu'une configuration qui fonctionne en 2.0.36 peut ne pas
d�marrer avec un noyau 2.2.6 (LILO n�cessite alors le mot-cl�
linear
, ou le noyau a besoin du param�tre aic7xxx=extended
au
d�marrage).
H=64 et S=32 � moins que C ne soit sup�rieur � 1024, ou que, encore mieux, le mode de conversion �tendu ait �t� autoris� au niveau du contr�leur, auquel cas si M<2^22 alors H=128, S=32 ; sinon H=255, S=63. Cependant, apr�s avoir fait ce choix pour (C,H,S), la table des partitions est lue et si pour l'une des trois possibilit�s (H,S)=(64,32),(128,32),(255,63) la valeur endH=H-1 est vue quelque part, alors cette paire est utilis�e et le message "Adopting Geometry from Partition Table" ("Adoption de la g�om�trie lue dans la table des partitions") est affich� au d�marrage.
Il trouve l'information sur la g�om�trie dans la Table des Param�tres des Disques du BIOS (BIOS Drive Parameter Table), ou lit la table des partitions et utilise H=endH+1, S=endS pour la premi�re partition, � condition qu'elle ne soit pas vide, ou utilise H=64, S=32 pour M<2^21 (1 Gio), H=128, S=63 pout M<63×2^17 (3.9 Gio) et H=255, S=63 dans les autres cas.
Il utilise le premier couple (H,S)=(64,32),(64,63),(128,63),(255,63) qui rendra C<1024. Dans le dernier cas, C est ramen� � la valeur 1023.
Il lit C,H,S depuis le disque dur. (Horreur !) Si C ou S sont trop grands, alors il fixe S=17, H=2 et double la valeur de H tant que C<=1024. Cela signifie que H sera mis � 0 si M>128×1024×17 (1.1 Gio). C'est un bug.
Un de ces trois couples de r�f�rence est utilis� ((H,S)=(16,63),(64,32),(64,63)) en fonction du mode de cartographie du contr�leur.
Regardez la table des partitions. Puisque par convention les partitions se
terminent � la limite d'un cylindre, nous pouvons, �tant donn� que
end=(endC,endH,endS)
pour n'importe quelle partition, simplement fixer
H=endH+1
et S=endS
. (Il est rappel� que le d�compte des
secteurs commence � 1.)
Plus pr�cis�ment, voil� ce qui est fait : s'il existe une partition non
vide, prendre la partition avec le plus grand begin
. Pour cette
partition, regarder endH+1
, calcul� � la fois en additionnant
start
et length
et en supposant le fait que cette partition se
termine � la limite d'un cylindre. Si les deux valeurs concordent, ou si
endC
=1023 et start+length
est un multiple entier de
(endH+1)xendS
, alors accepter le fait que cette partition se termine
effectivement sur la fronti�re d'un cylindre et fixer H=endH+1
et
S=endS
.
Si cela �choue, soit parce qu'il n'y a pas de partition, soit parce qu'elles ont
des tailles bizarres, il faut uniquement se fier � la capacit� totale M
du disque dur.
Algorithme : fixer H=M/
(62×1024) (arrondi au chiffre
sup�rieur), S=M/
(1024×H) (arrondi au chiffre sup�rieur),
C=M/
(H×S) (arrondi au chiffre inf�rieur).
Cela a pour effet de g�n�rer un triplet (C,H,S) avec C �gal � 1024 au plus et
S �gal � 62 au plus.
Le gestionnaire IDE de Linux obtient la g�om�trie et la capacit� d'un disque (et beaucoup d'autres choses) en utilisant une requ�te ATA IDENTIFY. R�cemment encore le gestionnaire ne croyait pas en la valeur retourn�e pour lba_capacity si elle �tait plus de 10% sup�rieure � la capacit� calcul�e par C×H×S. Cependant, par suite d'un accord entre les industriels, les disques IDE de grande capacit� donnent les valeurs C=16383, H=16 et S=63, pour un total de 16514064 secteurs (7.8 Go) ind�pendamment de leur taille r�elle, mais donnent cette taille r�elle dans lba_capacity.
Les noyaux r�cents de Linux (2.0.34, 2.1.90) savent cela et agissent en
cons�quence. Si vous avez un noyau Linux plus ancien et que vous ne voulez pas
passer � une version plus r�cente et que cedit noyau ne voit que 8 Gio
d'un bien plus gros disque dur, alors essayez de remplacer la routine
lba_capacity_is_ok
dans /usr/src/linux/drivers/block/ide.c
par
quelque chose du genre
static int lba_capacity_is_ok (struct hd_driveid *id) {
id->cyls = id->lba_capacity / (id->heads * id->sectors);
return 1;
}
Pour une modification plus s�re, voyez le noyau 2.1.90.
Comme nous venons de le dire, les gros disques durs donnent la g�om�trie
C=16383, H=16, S=63 ind�pendamment de leur vraie taille, alors que cette
derni�re est visible par la valeur de LBAcapacity.
Certains BIOS ne savent pas cela et convertissent ce 16383/16/63 en quelque
chose qui a moins de cylindres et plus de t�tes, par exemple 1024/255/63
ou 1027/255/63. Donc, le noyau ne doit pas seulement reconna�tre la
g�om�trie particuli�re 16383/16/63, mais �galement toutes ses versions
mutil�es par le BIOS.
Depuis le noyau 2.2.2 cela est fait correctement (en prenant la vision du
BIOS de H et S et en calculant C=capacit�/(H*S)
).
En g�n�ral, ce probl�me est r�solu en mettant le disque en mode Normal dans la
configuration du BIOS (ou, encore mieux, � None, ne le d�clarant pas du tout
au BIOS). Si cela est impossible parce que vous devez d�marrer � partir de ce
disque dur, ou l'utiliser avec DOS/Windows et que vous n'envisagez pas un
passage au noyau 2.2.2 ou mieux, utilisez les param�tres de d�marrage du
noyau.
Si un BIOS rapporte 16320/16/63, c'est en g�n�ral pour pouvoir aboutir � 1024/255/63 apr�s conversion.
Il y a ici, un autre probl�me.
Si le disque dur a �t� partitionn� en utilisant une conversion de g�om�trie,
alors le noyau peut, au moment du d�marrage, voir cette g�om�trie qui est
utilis�e dans la table des partitions et rapporter
hda: [PTBL] [1027/255/63]
.
Ce n'est pas bon parce que maintenant le disque dur n'est que de 8,4 Go.
Cela a �t� corrig� dans le noyau 2.3.21.
Encore un fois, les param�tres de d�marrage du noyau seront utiles.
Beaucoup de disques durs ont des cavaliers qui vous permettent de choisir entre des g�om�tries � 15 ou � 16 t�tes. Le r�glage par d�faut vous donnera une g�om�trie � 16 t�tes. Parfois, les deux g�om�tries adressent le m�me nombre de secteurs, parfois la version � 15 t�tes est plus petite. Vous devez avoir une bonne raison pour changer cette valeur : Petri Kaukasoina a �crit : "Un disque dur IBM Deskstar 16 GP de 10.1 Go (mod�le IBM-DTTA-351010) avait ses cavaliers positionn�s pour pr�senter 16 t�tes par d�faut mais ce vieux PC (avec un AMI BIOS) ne d�marrait pas et j'ai eu � modifier les cavaliers pour le faire passer en 15 t�tes. hdparm -i donne RawCHS=16383/15/63 et LBAsects=19807200. J'utilise 20960/15/63 pour avoir la capacit� totale." La g�om�trie 16383/15/63 n'est pas encore reconnue par le noyau, donc il est n�cessaire de donner explicitement ces param�tres au d�marrage. La g�om�trie 16383/15/63 n'est pas encore reconnue par le noyau, donc des param�tres de d�marrage explicites sont ici n�cessaires. Pour le positionnement des cavaliers voyez http://www.storage.ibm.com/techsup/hddtech/hddtech.htm.
De nombreux disques durs ont des cavaliers qui vous permettent de faire appara�tre leur taille inf�rieure � leur valeur r�elle. C'est une b�tise que de le faire et probablement aucun utilisateur de Linux ne voudra utiliser cette fonctionnalit�, mais certains BIOS plantent avec de gros disques. En g�n�ral la solution consiste � conserver le disque enti�rement en dehors du contr�le du BIOS. Cela n'est faisable que si ce disque dur n'est pas votre disque de d�marrage.
La premi�re limite s�rieuse fut celle des 4096 cylindres (soit, avec 16 t�tes et 63 secteurs par piste, 2,11 Go). Par exemple un disque dur Fujitsu MPB3032ATU de 3,24 Go a une g�om�trie par d�faut de 6704/15/63, mais ses cavaliers peuvent �tre positionn�s pour qu'elle apparaisse comme �tant 4092/16/63. Le disque rapportera une capacit� LBA de 4124736 secteurs et de ce fait le syst�me d'exploitation ne pourra pas deviner qu'il est en r�alit� plus grand. Dans un tel cas (avec un BIOS qui plante s'il sait que le disque dur est en r�alit� si grand et donc avec lequel les cavaliers sont n�cessaires) on aura besoin de param�tres de d�marrage pour donner � Linux la taille du disque.
C'est pas de chance. La plupart des disques durs ont des cavaliers qui peuvent �tre positionn�s pour qu'ils apparaissent comme �tant des 2 Go et pour qu'ils rapportent une g�om�trie tronqu�e comme 4092/16/63 ou 4096/16/63, mais qui leur permettent toujours de rapporter une capacit� LBA compl�te. De tels disques durs fonctionneront bien et utiliseront l'int�gralit� de leur capacit� sous Linux, que les cavaliers aient �t� positionn�s ou pas.
Une limite plus r�cente est celle des 33,8 Go. Les noyaux Linux plus anciens que le 2.2.14/2.3.21 n�cessitent l'application d'un correctif pour �tre capable de s'en sortir avec des disques durs IDE d'une taille plus importante que celle-l�.
Avec un vieux BIOS et un disque de plus de 33,8 Go, il se peut que le BIOS se bloque et dans ce cas il devient impossible de d�marrer, m�me lorsque le disque est retir� des options dans le CMOS. Vous pouvez regarder � cette adresse la limite du BIOS � 33,8 Go.
C'est pourquoi les disques de grande capacit� de chez Maxtor ou IBM disposent d'un cavalier qui les font apparaitre comme ayant une taille de 33,8 Go. Par exemple, l'IBM Deskstar 37,5 Go (DPTA-353750) avec 73261440 secteurs (ce qui correspond � 72680/16/63, ou � 4560/255/63) a un cavalier qui peut �tre positionn� de telle mani�re que le disque dur appara�t avec une taille de 33,8 Go et donc rapporte une g�om�trie de 16383/16/63 comme n'importe quel gros disque dur, mais avec une capacit� LBA de 66055248 (correspondant � 65531/16/63, ou � 4111/255/63). Ceci reste valable pour les disques de grande capacit� r�cents de chez Maxtor.
Quand le cavalier est positionn�, la g�om�trie (16383/16/63) et la taille (66055248) sont toutes deux conventionnelles et ne donnent aucune information sur la taille r�elle. De plus, si l'on essaye d'acc�der au secteur 66055248 ou plus, on obtient des erreurs d'entr�e/sortie. Cependant, sur les disques Maxtor, la taille r�elle peut �tre trouv�e et mise � disposition, � l'aide des commandes READ NATIVE MAX ADDRESS et SET MAX ADDRESS. Nous pouvons pr�sumer que c'est ce que font MaxBlast et EZ-Drive. Il existe �galement pour ceci un petit utilitaire Linux ( setmax.c) ainsi qu'un correctif pour le noyau.
Il y a un d�tail suppl�mentaire � pr�ciser en ce qui concerne les premiers gros disques de chez Maxtor : le cavalier J46 pour ces disques de 34-40 Go fait passer la g�om�trie de 16383/16/63 � 4092/16/63 et ne modifie pas la valeur donn�e de LBAcapacity. Ceci signifie que, m�me si le cavalier est pr�sent, les BIOS (les vieux Award 4.5*) se bloqueront au d�marrage. Pour ce cas pr�cis, Maxtor fournit l'utilitaire JUMPON.EXE qui met � jour le micro-code pour que le cavalier J46 se comporte comme d�crit ci-dessus.
Sur les disques Maxtor r�cents, la la commande setmax -d 0 /dev/hdX
vous donnera �galement acc�s � la capacit� maximale. Cependant, sur des disques
l�g�rement plus anciens, un bug du micro-code ne vous permet pas d'utiliser
-d 0
setmax -d 255 /dev/hdX
vous mettra pratiquement la
capacit� maximale.
Pour les Maxtor D540X-4K, voir plus bas.
Pour IBM les choses sont pires : le cavalier limite effectivement la
capacit� et il n'existe pas de solution logicielle pour retrouver la vraie
taille. La solution alors, n'est pas d'utiliser la cavalier mais de limiter par
voie logicielle la capacit� du disque avec la commande setmax -m 66055248
/dev/hdX
. "Comment ?" me direz-vous -- "Je ne peux
pas d�marrer !" IBM vous donne le truc : Si un syst�me avec
un BIOS Award bloque pendant la d�tection des disques, red�marrez votre syst�me
et maintenez la touch F4 enfonc�e pour court-circuiter l'autod�tection des
disques. Si cela ne fonctionne pas, trouvez un autre ordinateur, branchez-y
le disque et lancez-y la commande setmax
. Une fois que ceci est fait,
vous pouvez retourner sur votre premi�re machine et l�, la situation est
identique � ce qui se passe avec un Maxtor : vous parvenez � d�marrer et
une fois le BIOS pass� vous pouvez, soit appliquer un correctif au noyau, soit
ex�cuter la commande setmax -d 0
pour retrouver la capacit� maximale.
Les disques Maxtor Diamond Max 4K080H4, 4K060H3, 4K040H2 (alias D540X-4K) sont identiques aux disques 4D080H4, 4D060H3, 4D040H2 (alias D540X-4D), si ce n'est le configuration des cavaliers qui change. Une FAQ MAxtor donne les configurations Ma�tre/Esclave/CableSelect pour ces disques, mais le cavalier qui limite la capacit� des versions "4K" semble ne pas �tre document�. Nils Ohlmeier pr�tent avoir trouv� de mani�re exp�rimentale que c'est le cavalier J42 ("reserved for factory use" -- "r�serv� � une utilisation en usine"), � c�t� du connecteur d'alimentation (les disques "4D" utilisent le cavalier J46, comme les autres disques Maxtor).
Cependant, il se peut que ce cavalier non document� se comporte comme le
cavalier IBM : la machine d�marre sans probl�me mais le disque est limit� �
33 Go et setmax -d 0
ne permet pas de retrouver la capacit�
maximale. Et la solution IBM fonctionne : il ne faut pas limiter la
capacit� du disque avec le cavalier, mais d'abord le brancher � une
machine dont le BIOS est saint, le limiter par voie logicielle avec setmax
-m 66055248 /dev/hdX
et le remettre dans la premi�re machine. Apr�s avoir
d�marr�, la commande setmax -d 0 /dev/hdX
permet de retrouver la
capacit� maximale.
L'ioctl HDIO_GETGEO
retourne le nombre de cylindres dans un
short
. Cela signifie que si vous avez plus de 65535 cylindres, le
nombre est tronqu� et (pour une configuration SCSI typique avec 1 Mio de
cylindres) un disque de 80 Gio peut appara�tre comme ne faisant que
16 Gio. Une fois que le probl�me a �t� d�tect�, il est facile de l'�viter.
La convention de programmation est d'utiliser l'ioctl BLKGETSIZE
pour
obtenir la taille totale et HDIO_GETGEO
pour conna�tre le nombre de
t�tes et de secteurs par piste et, si n�cessaire, il est possible d'obtenir C
avec la formule C=taille/(H×S).
Ci-dessous se trouve une discussion sur les probl�mes du noyau Linux. Les probl�mes li�s au BIOS et au positionnement des cavalier ont-�t� trait�s ci-dessus.
Des unit�s d'une taille sup�rieure � 33,8 Go ne fonctionneront pas avec les noyaux ant�rieurs au 2.2.14/2.3.21. Les d�tails sont les suivants. Supposez que vous ayez achet� un tout nouveau disque dur IBM-DPTA-373420 qui offre une capacit� de 66835440 secteurs (34,2 Go). Les noyaux plus anciens que le 2.3.21 vous diront que la taille est de 769*16*63=775152 secteurs (0,4 Go), ce qui est quelque peu �tonnant. Et le fait de donner les param�tres hdc=4160,255,63 au d�marrage n'aide en rien -- ils sont tout simplement ignor�s. Que se passe-t-il ? La routine idedisk_setup() retrouve la g�om�trie rapport�e par le disque dur (qui est 16383/16/63) et �crase ce que l'utilisateur avait demand� sur la ligne de commande, de telle mani�re que les donn�es de l'utilisateur ne sont utilis�es que pour la g�om�trie du BIOS. La routine current_capacity() ou idedisk_capacity() recalcule le nombre de cylindres comme �tant 66835440/(16*63)=66305 mais comme il est stock� dans un short, il devient 769. Comme lba_capacity_is_ok() a d�truit id->cyls, tous les appels se solderont par un �chec et la capacit� du disque deviendra 769*16*63. Un correctif est disponible pour de nombreux noyaux. Un correctif pour le 2.0.38 peut �tre trouv� � ftp.kernel.org. Un correctif pour le 2.2.12 peut �tre trouv� � www.uwsg.indiana.edu (il se peut qu'il faille le modifier un peu pour se d�barrasser des tags html). Les noyaux 2.2.14 supportent ces disques durs. Dans la s�rie 2.3.* des noyaux, le support pour ces disques existe depuis le 2.3.21. Il est �galement possible de r�soudre ce probl�me avec une m�thode mat�rielle en positionnant des cavaliers pour limiter la taille � 33,8 Go. Dans la plupart des cas, une mise � jour du BIOS sera n�cessaire pour pouvoir d�marrer depuis ce disque dur.
Ci-dessus, nous avons vu la structure du MBR (secteur 0) : code du programme d'amor�age suivi par 4 entr�es de la table des partitions de 16 octets chacune, suivies par une signature AA55. Les entr�es de la table des partitions de type 5 ou F ou 85 (en hexad�cimal) ont une signification particuli�re : elles d�crivent les partitions �tendues : espaces qui seront ult�rieurement fractionn�s en partitions logiques. (Donc, une partition �tendue n'est qu'une bo�te et ne peut pas �tre utilis�e par elle-m�me ; on utilise alors les partitions logiques qu'elle contient.) Ce n'est que la position du premier secteur de la partition �tendue qui est important. Ce premier secteur contient une table des partitions avec quatre entr�es : une est une partition logique, une est une partition �tendue et deux sont inutilis�es. De cette mani�re, on obtient une cha�ne de secteurs de table des partitions, dispers�s sur le disque dur, o� le premier d�crit trois partitions primaires et la partition �tendue et chaque secteur de table des partitions qui suit d�crit une partition logique et la position du prochain secteur de table des partitions.
Il est important de comprendre cela : quand les gens font des b�tises en partitionnant leur disque, ils veulent savoir : "est-ce que mes donn�es sont toujours l� ?" Et la r�ponse est g�n�ralement : "oui". Mais si des partitions logiques ont �t� cr��es, alors les secteurs de table des partitions les d�crivant sont �crits au d�but des ces partitions logiques et les donn�es qui �taient initialement � ces emplacements sont perdues.
Le programme sfdisk
montre la cha�ne compl�te. Par exemple,
# sfdisk -l -x /dev/hda
Disk /dev/hda: 16 heads, 63 sectors, 33483 cylinders
Units = cylinders of 516096 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/hda1 0+ 101 102- 51376+ 83 Linux
/dev/hda2 102 2133 2032 1024128 83 Linux
/dev/hda3 2134 33482 31349 15799896 5 Extended
/dev/hda4 0 - 0 0 0 Empty
/dev/hda5 2134+ 6197 4064- 2048224+ 83 Linux
- 6198 10261 4064 2048256 5 Extended
- 2134 2133 0 0 0 Empty
- 2134 2133 0 0 0 Empty
/dev/hda6 6198+ 10261 4064- 2048224+ 83 Linux
- 10262 16357 6096 3072384 5 Extended
- 6198 6197 0 0 0 Empty
- 6198 6197 0 0 0 Empty
...
/dev/hda10 30581+ 33482 2902- 1462576+ 83 Linux
- 30581 30580 0 0 0 Empty
- 30581 30580 0 0 0 Empty
- 30581 30580 0 0 0 Empty
#
Il est possible de construire une mauvaise table des partitions. Beaucoup de
noyaux entrent dans une boucle s'il y a des partitions �tendues qui pointent sur
elles-m�mes ou sur une partition plac�e avant dans la cha�ne. Il est possible
d'avoir deux partitions �tendues dans un de ces secteurs de table des
partitions, de sorte que la cha�ne de la table de partitions se divise. (Cela
peut arriver par exemple avec un fdisk
qui ne reconna�t pas les
partitions typ�es 5, F ou 85 comme �tendues et qui cr�e une 5 � la suite d'une
F.) Des programmes de type fdisk
non standards peuvent provoquer de
telles situations et quelques manipulations sont n�cessaires pour les r�parer.
Le noyau de Linux acceptera une division au niveau le plus ext�rieur. Ainsi,
vous pouvez avoir deux cha�nes de partitions logiques. C'est parfois utile
-- par exemple, on peut utiliser pour l'une le type 5 afin qu'elle soit vue par DOS,
et pour l'autre le type 85, invisible pour DOS, ainsi DOS FDISK ne plantera pas �
cause d'une partition logique au-del� du cylindre 1024.
En g�n�ral il faut sfdisk
pour cr�er une telle configuration.
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.
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.
"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'.
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.