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.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:42