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;
}
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.