/usr/share/doc/HOWTO/fr-html/Large-Disk-HOWTO.html is in doc-linux-fr-html 2013.01-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.69">
<title>HOWTO - Disques de grande capacité</title>
</head>
<body>
<h1>HOWTO - Disques de grande capacité</h1>
<h2>Andries Brouwer, <code>aeb@cwi.nl</code>,<br>
version française par Xavier Serpaggi,
<code>xavier.serpaggi@libertysurf.fr</code></h2>
v2.2z, 2 février 2002
<hr>
<em>Tout sur la géométrie des disques durs et la
limite des 1024 cylindres. <!--
HOWTOs!large disk
-->
<!--
HOWTOs!disk, large
--></em>
<hr>
<p> </p>
<p>Pour obtenir une version toujours à jour, mais en
anglais, de ce document reportez-vous à la page <a href=
"http://www.win.tue.nl/~aeb/linux/Large-Disk.html">www.win.tue.nl</a>.</p>
<h2><a name="s1">1. Énoncé du
problème</a></h2>
<p><!--
disk drives!interaction with BIOS
-->
<!--
BIOS!interaction with disk drives
-->
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.</p>
<p>Heureusement, Linux ne se sert pas du BIOS, donc il n'y a pas de
problème.</p>
<p>Sauf peut-être pour deux choses :</p>
<p>(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.</p>
<p>(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
<code>fdisk</code>.</p>
<p>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.</p>
<h2><a name="s2">2. Résumé</a></h2>
<p>Vous avez un nouveau disque de grande capacité. Que
faire ? Bon, du côté logiciel il faut utiliser
<code>fdisk</code> (ou mieux, <code>cfdisk</code>), pour
créer les partitions, ensuite <code>mke2fs</code> pour
créer un système de fichiers et enfin
<code>mount</code> pour faire le lien entre ce nouveau
système de fichiers et l'arborescence déjà
existante.</p>
<p>Il n'est pas nécessaire de lire ce HOWTO à partir
du moment où, de nos jours, il n'y a <em>pas</em> 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 <code>fdisk</code>, ou encore
spécifient explicitement une géométrie de
disque à LILO ou sur la ligne de commande du noyau.</p>
<p>Cependant, les domaines dans lesquels interviennent typiquement
les problèmes sont :</p>
<ul>
<li>un matériel ancestral ;</li>
<li>plusieurs systèmes d'exploitation sur le même
disque dur ;</li>
<li>le démarrage.</li>
</ul>
<p>Conseil :</p>
<p>Pour les disques durs SCSI de grande capacité :
Linux les a très tôt supportés. Il n'y a rien
à faire.</p>
<p>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é.</p>
<p>Pour des disques durs IDE de capacité vraiment importante
(au-delà de 33,8 Go) : reportez-vous à la
section <a href="#verylarge">Problèmes de l'IDE avec des
disques durs de 34 Go et plus</a> plus bas dans ce
document.</p>
<p>Si LILO reste bloqué au démarrage, il faut essayer
de spécifier <code><a href="#linear">linear</a></code> dans
le fichier de configuration <code>/etc/lilo.conf</code> (et si
<code>linear</code> était déjà présent,
essayez sans). Si vous avez une version récente de LILO
(21.4 ou mieux), le mot-clé <code>lba32</code> 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).</p>
<p>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.</p>
<p>Si vous avez une vieille version de <code>fdisk</code> et qu'il
vous met des messages d'erreur du type <a href=
"#overlap">'overlapping partitions'</a> : ignorez-les ou
vérifiez en utilisant <code>cfdisk</code> que tout va
effectivement bien.</p>
<p>Pour le HPT366, reportez-vous au <a href=
"http://www.csie.ntu.edu.tw/~b6506063/hpt366/">Linux HPT366
HOWTO</a>.</p>
<p>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é.</p>
<p>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 <a href="#units">unités</a> binaires et
décimales et sachez que l'espace libre rapporté par
<code>df</code> 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.</p>
<p>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.</p>
<p>Maintenant, si vous pensez qu'il y a tout de même des
problèmes, ou simplement si vous êtes curieux, lisez
la suite.</p>
<h2><a name="units"></a> <a name="s3">3. Unités et
tailles</a></h2>
<p><!--
units!megabyte
-->
<!--
units!gigabyte
-->
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 <a href=
"http://physics.nist.gov/cuu/Units/prefixes.html">norme dans le
Système International</a> (SI).</p>
<p>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 <a href=
"http://physics.nist.gov/cuu/Units/binary.html">nouveau
standard</a> 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).</p>
<p>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 <code>fdisk</code>
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).</p>
<p>En ce qui concerne la terminologie et les abréviations
des unités binaires, <a href=
"http://www-cs-staff.stanford.edu/~knuth/">Knuth</a> propose une
<a href=
"http://www-cs-staff.stanford.edu/~knuth/news99.html">alternative</a>
qui est d'utiliser KKo, MMo, GGo, TTo, PPo, EEo, ZZo, YYo et de les
dénommer <em>grand kilo octet</em>, <em>grand méga
octet</em>, ... <em>grand yota octet</em>. Il écrit :
<i>"Remarquez que le fait de doubler la lettre a une connotation
à la fois binaire et d'amplitude."</i> C'est une bonne
proposition -- <em>grand giga octet</em> sonne mieux que
<em>gibi octet</em>. 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.</p>
<h2><a name="ss3.1">3.1 Taille d'un secteur</a></h2>
<p><!--
disk!sectorsize
-->
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 <code>fdisk</code>
sur de tels disques, assurez-vous d'avoir une version 2.9i ou
supérieure et passez-lui l'option
<code>-b 2048</code>.)</p>
<h2><a name="ss3.2">3.2 Taille d'un disque</a></h2>
<p><!--
disk!disksize
-->
Un disque avec C cylindres, H têtes (NdT : tête
se dit <em>head</em> 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.</p>
<h2><a name="s4">4. Accès à un disque dur</a></h2>
<p>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.</p>
<p>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.)</p>
<p>En conséquence, pour pouvoir utiliser un très
vieux disque non-SCSI, il faut connaître sa
<em>géométrie</em>, 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 : <a href=
"http://www.thetechpage.com/cgi-bin/default.cgi">www.thetechpage.com</a>.)</p>
<h2><a name="ss4.1">4.1 Accès disques du BIOS et la limite
des 1024 cylindres</a></h2>
<p>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 : <code>AH</code> sélectionne
la fonction à exécuter, <code>CH</code> correspond
aux 8 bits de poids faible du numéro de cylindre,
<code>CL</code> 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, <code>DH</code> est le numéro de la tête
et <code>DL</code> est le numéro du lecteur (80h ou 81h).
Cela explique en partie l'agencement de la table des
partitions.)</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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'.</p>
<h2><a name="ss4.2">4.2 Histoire du BIOS et des limites de
l'IDE</a></h2>
<dl>
<dt><b>Spécification ATA (pour les disques durs IDE)
-- la limite des 137 Go</b></dt>
<dd>
<p>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).</p>
</dd>
<dt><b>BIOS Int 13 -- la limite des 8,5 Go</b></dt>
<dd>
<p>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é.</p>
</dd>
<dt><b>La limite des 528 Mo</b></dt>
<dd>
<p>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.</p>
</dd>
<dt><b>La limite des 2,1 Go (avril 1996)</b></dt>
<dd>
<p>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 <a href=
"http://www.firmware.com/support/bios/over2gb.htm">plus de
2 Go</a>.</p>
</dd>
<dt><b>La limite des 3,2 Go</b></dt>
<dd>
<p>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 <a href=
"http://www.firmware.com/support/bios/over3gb.htm">plus de
3 Go</a>.</p>
</dd>
<dt><b>La limite des 4,2 Go (février 1997)</b></dt>
<dd>
<p>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
<a href="http://www.firmware.com/support/bios/over4gb.htm">plus de
4 Go</a>.</p>
</dd>
<dt><b>La limite des 7,9 Go</b></dt>
<dd>
<p>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.</p>
</dd>
<dt><b>La limite des 8,4 Go</b></dt>
<dd>
<p><a name="The 8.4 GB limit"></a> 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).)</p>
</dd>
<dt><b>La limite des 33,8 Go (août 1999)</b></dt>
<dd>
<p><a name="biosupgrades"></a> 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 à <a href=
"http://www.asus.com/Products/Motherboard/bios_slot1.html">Asus
upgrades</a> 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 <a href="#verylarge">les
problèmes posés par les disques durs IDE de
34 Go et plus</a> ci-dessous.</p>
</dd>
<dt><b>la limite des 137 Go (septembre 2001)</b></dt>
<dd>
<p>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.</p>
</dd>
</dl>
<p>Pour une autre discussion sur ce sujet, vous pouvez consulter la
page <a href=
"http://www.maxtor.com/products/DiamondMax/techsupport/Q&A/30004.html">
Breaking the Barriers</a> et pour encore plus de détails,
<a href=
"http://www.maxtor.com/technology/whitepapers/63001.html">IDE Hard
Drive Capacity Barriers</a>.</p>
<p>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.</p>
<h2><a name="s5">5. Démarrage</a></h2>
<p><!--
booting!BIOS usage during
-->
<!--
disk!BIOS access during booting
-->
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.</p>
<p>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.</p>
<p>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 <code>/boot</code> ; ainsi, LILO pourra y
mettre ses propres fichiers.</p>
<p>La plupart des systèmes depuis 1998 utilisent un BIOS
moderne.</p>
<h2><a name="linear"></a> <a name="ss5.1">5.1 LILO et les options
'lba32' et 'linear'</a></h2>
<p>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 : <a href=
"ftp://metalab.unc.edu/pub/Linux/system/boot/lilo/">ftp://metalab.unc.edu/pub/Linux/system/boot/lilo/</a>).</p>
<p>Un appel à <code>/sbin/lilo</code> (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.</p>
<p>Quand le fichier de configuration précise
<code>lba32</code> ou <code>linear</code>, des adresses
linéaires sont stockées. Avec l'option
<code>lba32</code> les adresses linéaires sont
également utilisées au moment du démarrage si
le BIOS supporte les extensions INT13 étendues. Avec
l'option <code>linear</code>, 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.</p>
<p>De ce fait, avec l'option <code>lba32</code> 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 ?</p>
<p>Le programme d'amorçage et le BIOS doivent être
d'accord sur la géométrie du disque dur.
<code>/sbin/lilo</code> 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 <code>linear</code>. 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 <code>lilo</code> 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.</p>
<h2><a name="ss5.2">5.2 Un bug de LILO</a></h2>
<p>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).</p>
<h2><a name="ss5.3">5.3 1024 cylindres ce n'est pas 1024
cylindres</a></h2>
<p>Tim Williams a écrit : <em>"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."</em> 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.</p>
<h2><a name="ss5.4">5.4 Plus de limite à 1024 cylindre sur
une vieille machine IDE</a></h2>
<p>Le chargeur d'amorce <code>nuni</code> 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 à <a href=
"ftp://metalab.unc.edu/pub/Linux/system/boot/loaders/">ftp://metalab.unc.edu/pub/Linux/system/boot/loaders/</a></p>
<h2><a name="overlap"></a> <a name="s6">6. Géométrie
du disque dur, partitions et 'overlap'</a></h2>
<p><!--
disk!geometry
-->
<!--
disk!partitions
-->
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.</p>
<p><a name="partitiontable"></a> Le MBR contient une <i>table des
partitions</i> qui décrit où se situent les
partitions (primaires). Il y a 4 entrées à la table,
pour 4 partitions primaires et chacune ressemble
à :</p>
<blockquote>
<pre>
<code>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 */
};
</code>
</pre></blockquote>
(avec CHS qui signifie Cylinder/Head/Sector
-- Cylindre/Tête/Secteur).
<p>Cette information est redondante : la position de la
partition est donnée à la fois par les champs
<code>begin</code> et <code>end</code> codés sur
24 bits et par les champs <code>start</code> et
<code>length</code> codés sur 32 bits.</p>
<p>Linux ne se sert que des champs <code>start</code> et
<code>length</code> 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.)</p>
<p>DOS utilise les champs <code>begin</code> et <code>end</code> 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.*.</p>
<p>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
<code>begin</code> et <code>end</code> 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.</p>
<p>Qu'est-ce que c'est que ce message insensé que vous
rapporte <code>fdisk</code> 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
<code>begin</code> et <code>end</code> 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 <code>start</code>
et <code>length</code>, 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 <code>cfdisk</code> 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 <code>cfdisk -Ps /dev/hdx</code> et
<code>cfdisk -Pt /dev/hdx</code> pour voir la table des partitions
du disque <code>/dev/hdx</code>.</p>
<h2><a name="ss6.1">6.1 Le dernier cylindre</a></h2>
<p>Un nombre important de vieux IBM PS/2 utilisent des disques
durs avec une carte des <i>défaillances</i> écrite
à la fin du disque (le bit 0x20 dans le mot de controle de
<a href=
"http://www.win.tue.nl/~aeb/linux/hdtypes/hdtypes-2.html">la table
de paramètrage du disque</a> 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.</p>
<h2><a name="ss6.2">6.2 Limites du cylindre</a></h2>
<p>La croyance populaire racconte que les partitions doivent
commencer et finir aux frontières des cylindres.</p>
<p>Puisque <em>la géométrie des disques</em> 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.</p>
<p>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).</p>
<p>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.</p>
<p>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).</p>
<p>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 <code>cfdisk</code> explique que les
vieilles versions de DOS n'alignaient pas les partitions.</p>
<p>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.</p>
<p>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).</p>
<h2><a name="s7">7. Conversion et Gestionnaires de Disques
Durs</a></h2>
<p><!--
disk!geometry translation
-->
<!--
BIOS!translating
-->
<!--
BIOS!LBA support
-->
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.</p>
<p>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.</p>
<p>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.</p>
<p>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 :
<a href="#The%208.4%20GB%20limit">La limite des 8,4 Go</a>.</p>
<p>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).</p>
<p>(La troisième option de configuration est 'Normal', pour
laquelle aucune conversion n'est effectuée.)</p>
<p>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é.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="s8">8. Conversions du noyau pour les disques durs
IDE</a></h2>
<p><!--
disk!translation done by kernel
-->
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
'<code>hd=</code><i>cyls</i><code>,</code><i>têtes</i><code>,</code><i>secs</i>'
peut très bien briser la compatibilité avec un
gestionnaire de disque.</p>
<p>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 <code>linux/drivers/block/ide.c</code> et
supprimez, dans la routine <code>ide_xlate_1024()</code>, le test
<code>if (drive->forced_geom) { ...; return 0; }</code>.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="ss8.1">8.1 EZD</a></h2>
<p><!--
disk!EZ-Drive translation
-->
<!--
disk!EZD translation
-->
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
<code>#define FAKE_FDISK_FOR_EZDRIVE 0</code> dans
<code>ide.c</code>.</p>
<h2><a name="ss8.2">8.2 DM6 : DDO</a></h2>
<p><!--
disk!OnTrack DiskManager translation
-->
<!--
disk!DM6:DD0 translation
-->
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.</p>
<h2><a name="ss8.3">8.3 DM6 : AUX</a></h2>
<p><!--
disk!OnTrack DiskManager translation
-->
<!--
disk!DM6:AUX
-->
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.</p>
<h2><a name="ss8.4">8.4 DM6 : MBR</a></h2>
<p><!--
disk!OnTrack DiskManager translation
-->
<!--
disk!DM6:MBR
-->
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 <code>short</code>
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.</p>
<h2><a name="ss8.5">8.5 PTBL</a></h2>
<p><!--
disk!PTBL translation
-->
Finalement, il y a un test qui tente de déduire une
conversion à partir des valeurs <code>start</code> et
<code>end</code> 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é).</p>
<h2><a name="ss8.6">8.6 Comment se débarasser d'un
gestionnaire de disque</a></h2>
<p>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 <code>ide_xlate_1024()</code> 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</p>
<blockquote>
<pre>
<code> dd if=/dev/zero of=/dev/hdx bs=512 count=1
</code>
</pre></blockquote>
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
<code>hda=remap</code> et <code>hdb=noremap</code>. 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
<code>hdX=noremap</code> permet également d'éviter le
décalage dû au gestionnaire
Ontrack Disk Manager.
<h2><a name="s9">9. Conséquences</a></h2>
<p><!--
disk!consequences of translation
-->
Qu'est-ce que tout cela signifie ? Pour les utilisateurs de
Linux seulement une chose : qu'ils doivent s'assurer que LILO
et <code>fdisk</code> utilisent la bonne géométrie,
où 'bonne' pour <code>fdisk</code> 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).</p>
<p>Comment <code>fdisk</code> connaît-il la
géométrie ? Il demande au noyau en utilisant
l'ioctl <code>HDIO_GETGEO</code>. Mais l'utilisateur peut passer
outre cela en précisant la géométrie de
manière interactive, ou sur la ligne de commande.</p>
<p>Comment LILO connaît-il la géométrie ?
Il demande au noyau en utilisant l'ioctl <code>HDIO_GETGEO</code>.
Mais l'utilisateur peut passer outre cela en utilisant l'option
'<code>disk=</code>' dans le fichier <code>/etc/lilo.conf</code>
(voyez la page de manuel lilo.conf(5)). On peut également
passer l'option <code>linear</code> à 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).</p>
<p>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
'<code>hda=</code><i>cyls</i><code>,</code><i>têtes</i><code>,</code><i>secs</i>'
(voyez la page de manuel bootparam(7)). Par exemple, vous pouvez
demander à LILO de fournir une telle option en ajoutant une
ligne
'<code>append="hda=</code><i>cyls</i><code>,</code><i>têtes</i><code>,</code><i>secs</i><code>"</code>'
dans le fichier <code>/etc/lilo.conf</code> (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.</p>
<p>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 <code>/proc</code>. Par
exemple :</p>
<blockquote>
<pre>
<code># 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
#
</code>
</pre></blockquote>
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).
<p>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é <a href=
"http://www.heise.de/ct/faq/hotline/98/07/hotline9807_11.shtml">rapporté</a>
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 <a href=
"http://www.heise.de/ct/faq/hotline/98/19/hotline9819_11.shtml">rapport</a> :
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.</p>
<p>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 <a href="#jumpers">plus bas</a>.
Parfois, certains utilitaires permettent de changer le micro-code
du disque dur.</p>
<h2><a name="ss9.1">9.1 Calcul des paramètres de
LILO</a></h2>
<p>Parfois il est utile de forcer une certaine
géométrie en ajoutant
'<code>hda=</code><i>cyls</i><code>,</code><i>têtes</i><code>,</code><i>secs</i>'
à la ligne de commande du noyau. On voudra pratiquement
toujours <i>secs</i>=63 et le but recherché en ajoutant cela
est de spécifier <i>têtes</i>. (Des valeurs
raisonnables de nos jours sont <i>têtes</i>=16 et
<i>têtes</i>=255.) Que devra-t-on mettre pour
<i>cyls</i> ? 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 <code>bc</code>) et on donnera le
paramètre de démarrage <code>hdc=4441,255,63</code>.
Comment connaît-on la capacité totale exacte ?
Par exemple,</p>
<blockquote>
<pre>
<code># 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
</code>
</pre></blockquote>
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 :
<blockquote>
<pre>
<code># 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 >
</code>
</pre></blockquote>
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 :
<blockquote>
<pre>
<code>SCSI device sda: 17755792 512-byte hdwr sectors (9091 MB)
</code>
</pre></blockquote>
<h2><a name="s10">10. Détails</a></h2>
<h2><a name="ss10.1">10.1 Détails de l'IDE - les sept
géométries</a></h2>
<p><!--
disk!IDE geometry setting
-->
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 <a href="#identify">IDENTIFY</a> -- ce
sont les géométries 'physique' et 'logique du
moment'.</p>
<p>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 <code>HDIO_GETGEO</code> 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.</p>
<p>En d'autres termes : la ligne de commande prend le pas sur
le BIOS et va déterminer ce que va voir <code>fdisk</code>,
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.</p>
<p>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.</p>
<h3><a name="identify"></a> Commande IDENTIFY DRIVE</h3>
<p>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.</p>
<p>Nous trouvons ici trois informations : DefaultCHS (mots
1,3,6), CurrentCHS (mots 54-58) et LBAcapacity (mots 60-61).</p>
<p><br></p>
<center>
<table border>
<tr>
<td></td>
<td>Description</td>
<td>Exemple</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td>0</td>
<td>Champ de bits : bit 6 : disque fixe, bit 7 :
media amovible</td>
<td>0x0040</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td>1</td>
<td>Nombre par défaut de cylindres</td>
<td>16383</td>
</tr>
<tr>
<td>3</td>
<td>Nombre par défaut de têtes</td>
<td>16</td>
</tr>
<tr>
<td>6</td>
<td>Nombre par défautl de secteurs par piste</td>
<td>63</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td>10-19</td>
<td>Numéro de série (en ASCII)</td>
<td>K8033FEC</td>
</tr>
<tr>
<td>23-26</td>
<td>Révision du micro-code (en ASCII)</td>
<td>DA620CQ0</td>
</tr>
<tr>
<td>27-46</td>
<td>Nom du modèle (en ASCII)</td>
<td>Maxtor 54098U8</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td>49</td>
<td>Champ de bits : bit 9 : supporte le LBA</td>
<td>0x2f00</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td>53</td>
<td>Champ de bits : bit 0 : les mots 54-58 sont
valides</td>
<td>0x0007</td>
</tr>
<tr>
<td>54</td>
<td>Nombre actuel de cylindres</td>
<td>16383</td>
</tr>
<tr>
<td>55</td>
<td>Nombre actuel têtes</td>
<td>16</td>
</tr>
<tr>
<td>56</td>
<td>Nombre actuel de secteurs par piste</td>
<td>63</td>
</tr>
<tr>
<td>57-58</td>
<td>Nombre total actuel de secteurs</td>
<td>16514064</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td>60-61</td>
<td>Nombre par défaut de secteurs</td>
<td>80041248</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td>255</td>
<td><em>Checksum</em> et signature (0xa5)</td>
<td>0xf9a5</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td></td>
</tr>
</table>
</center>
<br>
<p>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).</p>
<p>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).</p>
<h2><a name="ss10.2">10.2 Détails pour le SCSI</a></h2>
<p><!--
disk!SCSI geometry setting
-->
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 <code>fdisk</code> 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.</p>
<p>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.</p>
<p>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 à <code>fdisk</code> 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 à <code>fdisk</code>, à LILO ou au
noyau la véritable géométrie d'un disque
SCSI.</p>
<p>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
<code>scsiinfo</code> 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'à <code>fdisk</code> 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 <code>fdisk</code> parce que la table des
partitions ne réserve que 10,8 et 6 bits pour respectivement
C/H/S.</p>
<p>Mais alors, d'où le <code>HDIO_GETGEO</code> 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.</p>
<p>Remarquez que le <code>fdisk</code> 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
<code>fdisk</code> à n'avoir accès qu'à
environ 8 Gio de leur disque -- une sérieuse
limitation de nos jours.</p>
<p>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).</p>
<p>Par défaut, H=64 et S=32.</p>
<dl>
<dt><b>aha1740, dtc, g_NCR5380, t128, wd7000 :</b></dt>
<dd>
<p>H=64, S=32.</p>
</dd>
<dt><b>aha152x, pas16, ppa, qlogicfas, qlogicisp :</b></dt>
<dd>
<p>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 <code>fdisk</code>.) Le
code de <code>ppa.c</code> utilise M+1 à la place de M et
dit qu'à cause d'un bug dans <code>sd.c</code>, M est plus
petit de 1.</p>
</dd>
<dt><b>advansys :</b></dt>
<dd>
<p>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.</p>
</dd>
<dt><b>aha1542 :</b></dt>
<dd>
<p>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")</p>
</dd>
<dt><b>aic7xxx :</b></dt>
<dd>
<p>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é <code>linear</code>,
ou le noyau a besoin du paramètre
<code>aic7xxx=extended</code> au démarrage).</p>
</dd>
<dt><b>buslogic :</b></dt>
<dd>
<p>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.</p>
</dd>
<dt><b>fdomain :</b></dt>
<dd>
<p>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.</p>
</dd>
<dt><b>in2000 :</b></dt>
<dd>
<p>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.</p>
</dd>
<dt><b>seagate :</b></dt>
<dd>
<p>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.</p>
</dd>
<dt><b>ultrastor et u14_34f :</b></dt>
<dd>
<p>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.</p>
</dd>
</dl>
Si le gestionnaire ne précise pas la
géométrie, nous retombons dans un mode de supposition
guidé par la table des partitions, ou par la capacité
totale du disque dur.
<p>Regardez la table des partitions. Puisque par convention les
partitions se terminent à la limite d'un cylindre, nous
pouvons, étant donné que
<code>end=(endC,endH,endS)</code> pour n'importe quelle partition,
simplement fixer H=<code>endH+1</code> et S=<code>endS</code>. (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 <code>begin</code>. Pour cette
partition, regarder <code>endH+1</code>, calculé à la
fois en additionnant <code>start</code> et <code>length</code> et
en supposant le fait que cette partition se termine à la
limite d'un cylindre. Si les deux valeurs concordent, ou si
<code>endC</code>=1023 et <code>start+length</code> est un multiple
entier de <code>(endH+1)xendS</code>, alors accepter le fait que
cette partition se termine effectivement sur la frontière
d'un cylindre et fixer H=<code>endH+1</code> et
S=<code>endS</code>. 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<code>/</code>(62×1024) (arrondi au chiffre
supérieur), S=M<code>/</code>(1024×H) (arrondi au
chiffre supérieur), C=M<code>/</code>(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.</p>
<h2><a name="s11">11. Limite de Linux pour l'IDE à 8
Gio</a></h2>
<p>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 <a href=
"#identify">ATA IDENTIFY</a>. 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.</p>
<p>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
<code>lba_capacity_is_ok</code> dans
<code>/usr/src/linux/drivers/block/ide.c</code> par quelque chose
du genre</p>
<blockquote>
<pre>
<code>static int lba_capacity_is_ok (struct hd_driveid *id) {
id->cyls = id->lba_capacity / (id->heads * id->sectors);
return 1;
}
</code>
</pre></blockquote>
Pour une modification plus sûre, voyez le noyau 2.1.90.
<h2><a name="ss11.1">11.1 Complications du BIOS</a></h2>
<p>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
<code>C=capacité/(H*S)</code>). 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.</p>
<p>Si un BIOS rapporte 16320/16/63, c'est en général
pour pouvoir aboutir à 1024/255/63 après
conversion.</p>
<p>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
<code>hda: [PTBL] [1027/255/63]</code>. 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.</p>
<h2><a name="jumpers"></a> <a name="ss11.2">11.2 Des cavaliers pour
sélectionner le nombre de têtes</a></h2>
<p>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 : <i>"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."</i> 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 <a href=
"http://www.storage.ibm.com/techsup/hddtech/hddtech.htm">http://www.storage.ibm.com/techsup/hddtech/hddtech.htm</a>.</p>
<h2><a name="ss11.3">11.3 Des cavaliers pour limiter la
capacité totale</a></h2>
<p>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.</p>
<h3>Limitation à 2,1 Go</h3>
<p>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.</p>
<p>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.</p>
<h3><a name="jumperbig"></a> Limitation à 33 Go</h3>
<p>Une limite plus récente est celle des <a href=
"#verylarge">33,8 Go</a>. 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à.</p>
<p>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
<a href=
"http://www.storage.ibm.com/techsup/hddtech/bios338gb.htm">la
limite du BIOS à 33,8 Go</a>.</p>
<p>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.</p>
<h3>Maxtor</h3>
<p>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 ( <a href=
"http://www.win.tue.nl/~aeb/linux/setmax.c">setmax.c</a>) ainsi
qu'un correctif pour le noyau.</p>
<p>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 <a href=
"http://www.maxtor.com/technology/technotes/20012.html">JUMPON.EXE</a>
qui met à jour le micro-code pour que le cavalier J46 se
comporte comme décrit ci-dessus.</p>
<p>Sur les disques Maxtor récents, la la commande
<code>setmax -d 0 /dev/hdX</code> 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 <code>-d 0</code>
<code>setmax -d 255 /dev/hdX</code> vous mettra pratiquement la
capacité maximale. Pour les Maxtor D540X-4K, voir plus
bas.</p>
<h3>IBM</h3>
<p>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 <code>setmax -m 66055248
/dev/hdX</code>. <em>"Comment ?"</em> me direz-vous
-- <em>"Je ne peux pas démarrer !"</em> IBM vous
donne le truc : <i>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.</i> Si cela ne
fonctionne pas, trouvez un autre ordinateur, branchez-y le disque
et lancez-y la commande <code>setmax</code>. 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 <code>setmax -d 0</code>
pour retrouver la capacité maximale.</p>
<h3>Maxtor D540X-4K</h3>
<p>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 (<i>"reserved for factory use"</i>
-- "réservé à une utilisation en usine"),
à côté du connecteur d'alimentation (les
disques "4D" utilisent le cavalier J46, comme les autres disques
Maxtor).</p>
<p>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 <code>setmax -d 0</code> 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 <code>setmax -m
66055248 /dev/hdX</code> et le remettre dans la première
machine. Après avoir démarré, la commande
<code>setmax -d 0 /dev/hdX</code> permet de retrouver la
capacité maximale.</p>
<h2><a name="s12">12. Limite de Linux à
65535 cylindres</a></h2>
<p>L'ioctl <code>HDIO_GETGEO</code> retourne le nombre de cylindres
dans un <code>short</code>. 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.</p>
<p>La convention de programmation est d'utiliser l'ioctl
<code>BLKGETSIZE</code> pour obtenir la taille totale et
<code>HDIO_GETGEO</code> 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).</p>
<h2><a name="verylarge"></a> <a name="ss12.1">12.1 Problèmes
de l'IDE avec des disques durs de 34 Go et plus</a></h2>
<p>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
<a href="#jumperbig">ci-dessus</a>.</p>
<p>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é à <a href=
"ftp://ftp.us.kernel.org/pub/linux/kernel/people/aeb/">ftp.kernel.org</a>.
Un correctif pour le 2.2.12 peut être trouvé à
<a href=
"http://www.uwsg.indiana.edu/hypermail/linux/kernel/9910.2/0636.html">
www.uwsg.indiana.edu</a> (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 <a href=
"#jumperbig">positionnant des cavaliers</a> pour limiter la taille
à 33,8 Go. Dans la plupart des cas, une <a href=
"#biosupgrades">mise à jour du BIOS</a> sera
nécessaire pour pouvoir démarrer depuis ce disque
dur.</p>
<h2><a name="s13">13. Partitions étendues et partitions
logiques</a></h2>
<p><a href="#partitiontable">Ci-dessus</a>, 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
<i>étendues</i> : espaces qui seront
ultérieurement fractionnés en partitions
<i>logiques</i>. (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.</p>
<p>Il est important de comprendre cela : quand les gens font
des bêtises en partitionnant leur disque, ils veulent
savoir : <i>"est-ce que mes données sont toujours
là ?"</i> Et la réponse est
généralement : <i>"oui"</i>. 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.</p>
<p>Le programme <code>sfdisk</code> montre la chaîne
complète. Par exemple,</p>
<blockquote>
<pre>
<code># 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
#
</code>
</pre></blockquote>
<p>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
<code>fdisk</code> 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
<code>fdisk</code> 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 <code>sfdisk</code> pour créer
une telle configuration.</p>
<h2><a name="s14">14. Résolution des
problèmes</a></h2>
<p>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é
<code>lba32</code> 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 à
<code>fdisk</code> 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.</p>
<p>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 <code>fdisk</code>. 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.</p>
<h2><a name="ss14.1">14.1 Problème : La
géométrie de mon disque dur IDE est fausse quand je
démarre depuis du SCSI.</a></h2>
<p>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.</p>
<h2><a name="ss14.2">14.2 Faux problème : des disques
identiques ont des géométries
différentes ?</a></h2>
<p><i>"Je possède deux disques durs IBM identiques de
10 Go. Cependant, <code>fdisk</code> donne des tailles
différentes pour les deux. Voyez :</i></p>
<blockquote>
<pre>
<code># 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
</code>
</pre></blockquote>
<i>Comment cela est-il possible ?"</i>
<p>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.</p>
<p>Si vous voulez recartographier hdd de la même
manière, donnez au noyau l'option de démarrage
'hdd=1232,255,63'.</p>
<h2><a name="ss14.3">14.3 Faux problème :
<code>fdisk</code> voit beaucoup plus d'espace que
df ?</a></h2>
<p><code>fdisk</code> 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 :</p>
<blockquote>
<pre>
<code># 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
#
</code>
</pre></blockquote>
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 :
<blockquote>
<pre>
<code># 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
#
</code>
</pre></blockquote>
À 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.
</body>
</html>
|