Large Disk HOWTO <author>Andries Brouwer, <tt/aeb@cwi.nl/ 著 <date>v2.2j, 12 September 1999 <trans>平本 光二 <tt/hiramoto@nanako.or.jp/ 訳 <tdate>2000年2月18日作成 <abstract> <!-- All about disk geometry and the 1024 cylinder limit for disks. --> ディスクのジオメトリと1024シリンダ制限のすべて。 <nidx>HOWTOs!large disk</nidx> <nidx>HOWTOs!disk, large</nidx> </abstract> <p> <!-- For the most recent version of this text, see <htmlurl url="http://www.win.tue.nl/~aeb/linux/Large-Disk.html" name="www.win.tue.nl">. --> この文書の最新バージョンは、 <htmlurl url="http://www.win.tue.nl/~aeb/linux/Large-Disk.html" name="www.win.tue.nl"> を参照してください。 (訳注: オリジナルの英語版のこと。日本語版の最新バージョンについては <htmlurl url="http://www.linux.or.jp/JF/" name="www.linux.or.jp"> を参照してください) <sect> <!-- The problem --> 問題 <p> <nidx>disk drives!interaction with BIOS</nidx> <nidx>BIOS!interaction with disk drives</nidx> <!-- Suppose you have a disk with more than 1024 cylinders. Suppose moreover that you have an operating system that uses the old INT13 BIOS interface to disk I/O. Then you have a problem, because this interface uses a 10-bit field for the cylinder on which the I/O is done, so that cylinders 1024 and past are inaccessible. --> 例えばあなたが 1024 シリンダを超えるディスクを持っているとしましょう。 その上あなたがディスク I/O のために古い INT13 BIOS インターフェースを使う OS を持っているとしましょう。 これは問題です。 なぜなら、このインターフェースは I/O 動作時のシリンダ指定に 10 ビットのフィールドを使うので、 1024 番以降のシリンダにはアクセスできないのです。 (訳注: 2^10 = 1024) <p> <!-- Fortunately, Linux does not use the BIOS, so there is no problem. --> 幸い、Linux は BIOS を使いませんので問題ありません。 <p> <!-- Well, except for two things: --> まぁ、次の二点を除いてですが。 <enum> <!-- (1) When you boot your system, Linux isn't running yet and cannot save you from BIOS problems. This has some consequences for LILO and similar boot loaders. --> <item>システム起動時には Linux はまだ稼動していませんので、 BIOS 問題から逃げられません。 これは LILO やそれに類するブートローダにとって問題になります。 <!-- (2) It is necessary for all operating systems that use one disk to agree on where the partitions are. In other words, if you use both Linux and, say, DOS on one disk, then both must interpret the partition table in the same way. This has some consequences for the Linux kernel and for <tt/fdisk/. --> <item>複数の OS で一つのディスクを使いまわす場合、 どこにパーティションがあるのか、 それぞれの OS がしっかり把握していなければなりません。 言い換えると、Linux と DOS を一つのディスク上で使用する場合、 両者は同じ方法でパーティションテーブルを解釈する必要があります。 これは Linux カーネルと <tt/fdisk/ にとって問題になります。 </enum> <!-- Below a rather detailed description of all relevant details. Note that I used kernel version 2.0.8 source as a reference. Other versions may differ a bit. --> 以下に、関連する問題の詳細を示します。 なお、私はカーネルのバージョン2.0.8 を参照しています。 他のバージョンでは少し違うかもしれません。 <sect> <!-- Summary --> 要約 <p> <!-- You got a new large disk. What to do? Well, on the software side: use <tt/fdisk/ (or, better, <tt/cfdisk/) to create partitions, and then <tt/mke2fs/ to create a filesystem, and then <tt/mount/ to attach the new filesystem to the big file hierarchy. --> 新しい大容量ディスクを用意しました。どうすればいいんしょう? そう、ソフトウェア的には、<tt/fdisk/ (<tt/cfdisk/ の方がよりよい) でパーティションを作成し、mke2fs でファイルシステムを作り、 mount で新しいファイルシステムをファイル階層に追加すればいいんです。 <p> <!-- You need not read this HOWTO since there are <em/no/ problems with large hard disks these days. The great majority of apparent problems is caused by people who think there might be a problem and install a disk manager, or go into <tt/fdisk/ expert mode, or specify explicit disk geometries to LILO or on the kernel command line. --> 最近では大容量ハードディスクについて問題になることはまず無いので、 この HOWTO を読む必要もまず無いでしょう。 問題のように思われるものの大部分は、 大容量ハードディスクを使用する上で問題になるだろうと思い込んで ディスクマネージャをインストールしたり、 <tt/fdisk/ のエキスパートモードにいっちゃったり、 明示的にディスクのジオメトリを LILO やカーネルのコマンドラインで指定したりすることによって引き起こされます。 <p> <!-- However, typical problem areas are: (i) ancient hardware, (ii) several operating systems on the same disk, and sometimes (iii) booting. --> しかし、典型的な問題は以下のようなものです。 <enum> <item>太古のハードウェアを使ってる <item>同じディスク上にいくつかの OS を載せる <item>起動時(時々起きる) </enum> <!-- Advice: For large SCSI disks: Linux has supported them from very early on. No action required. For large IDE disks (over 8.4 GB): get a recent stable kernel (2.0.34 or later). Usually, all will be fine now, especially if you were wise enough not to ask the BIOS for disk translations like LBA and the like. For very large IDE disks (over 33.8 GB): see <ref id="verylarge" name="IDE problems with 34+ GB disks"> below. If LILO hangs at boot time, also specify <tt><ref id="linear" name="linear"></tt> in the configuration file <tt>/etc/lilo.conf</tt>. There may be geometry problems that can be solved by giving an explicit geometry to kernel/LILO/fdisk. If you have an old <tt/fdisk/ and it warns about <ref id="overlap" name="overlapping"> partitions: ignore the warnings, or check using <tt/cfdisk/ that really all is well. If you think something is wrong with the size of your disk, make sure that you are not confusing binary and decimal <ref id="units">, and realize that the free space that <tt/df/ reports on an empty disk is a few percent smaller than the partition size, because there is administrative overhead. --> アドバイス: 大容量 SCSI ディスクについて: Linux はずっと昔からサポートしています。 特別なことをする必要はありません。 (8.4GB を越えるような) 大容量 IDE ディスクについて: 最新の安定版カーネル (2.0.34 かそれ以降)を使ってください。 通常はそれが一番です。 特に、BIOS に LBA などのディスク (ジオメトリ) 変換を要求しないという 賢明な選択ができるような場合には。 (33.8GB を越えるような) とても大容量の IDE ディスクについて: 後述の <ref id="verylarge" name="34GB を越えるディスクでの IDE の問題"> を参照してください。 もし起動時に LILO がハングしたら、 設定ファイルの <tt>/etc/lilo.conf</tt> に <tt><ref id="linear" name="linear"></tt> も指定してください。 カーネル/LILO/fdisk に明示的にジオメトリを与えることにより解決するような ジオメトリの問題であるかもしれません。 古い <tt/fdisk/ を使っていて、 パーティションが重なっている(<ref id="overlap" name="overlapping">) という警告が出たら: 警告は無視するか、<tt/cfdisk/ を使ってください(こちらの方がよい)。 ディスクのサイズが何か変だと思う時は、 二進と十進の <ref id="unit" name="単位"> を混同していないか確認してください。 そして、空き領域を調べるために <tt/df/ を使用する時は、 <tt/df/ は管理上のオーバーヘッドのために空のディスク上でも パーティションサイズより数パーセント小さい値を報告することを 覚えておいてください。 (訳注: 詳細は <ref id="df_fdisk" name="「問題なし: df より fdisk の方がパーティションが大きく見える」"> の章を参照してください) <p> <!-- Now, if you still think there are problems, or just are curious, read on. --> さぁ、これでもまだ何か問題があると思われるのならば、 あるいはあなたが単に知りたがりやならば、以下も読んでください。 <sect> <!-- Units and Sizes --> 単位とサイズ <label id="unit"> <p> <nidx>units!megabyte</nidx> <nidx>units!gigabyte</nidx> <!-- A kilobyte (kB) is 1000 bytes. A megabyte (MB) is 1000 kB. A gigabyte (GB) is 1000 MB. A terabyte (TB) is 1000 GB. This is the <htmlurl url="http://physics.nist.gov/cuu/Units/prefixes.html" name="SI norm">. However, there are people that use 1 MB=1024000 bytes and talk about 1.44 MB floppies, and people who think that 1 MB=1048576 bytes. Here I follow the <htmlurl url="http://physics.nist.gov/cuu/Units/binary.html" name="recent standard"> and write Ki, Mi, Gi, Ti for the binary units, so that these floppies are 1440 KiB (1.47 MB, 1.41 MiB), 1 MiB is 1048576 bytes (1.05 MB), 1 GiB is 1073741824 bytes (1.07 GB) and 1 TiB is 1099511627776 bytes (1.1 TB). --> 1キロバイト (kB) = 1000バイト。 1メガバイト (MB) = 1000 kB。 1ギガバイト (GB) = 1000 MB。 1テラバイト (TB) = 1000 GB。 これは <htmlurl url="http://physics.nist.gov/cuu/Units/prefixes.html" name="SI 単位系"> です。 しかし、1 MB = 1024000バイトを適用して 1.44 MB フロッピーと表現したり、 1 MB = 1048576バイトと考える人がいます。 この文書では、二進法の方を Ki, Mi, Gi, Ti と表現して、これを <htmlurl url="http://physics.nist.gov/cuu/Units/binary.html" name="標準"> とします。 そうすると、フロッピーは 1440 KiB (1.47 MB, 1.41 MiB) となり、 1 MiB = 1048576 バイト (1.05 MB) 1 GiB = 1073741824 バイト (1.07 GB) 1 TiB = 1099511627776 バイト (1.1 TB) となります。 <p> <!-- Quite correctly, the disk drive manufacturers follow the SI norm and use the decimal units. However, Linux boot messages and some fdisk-type programs use the symbols MB and GB for binary, or mixed binary-decimal units. So, before you think your disk is smaller than was promised when you bought it, compute first the actual size in decimal units (or just in bytes). --> まったく正しいことに、 ディスクドライブのメーカは SI 単位系に従い十進法を使っています。 しかし、Linux の起動メッセージやいくつかの fdisk のようなプログラムは 二進法を表現するために MB や GB というシンボルを使用してたり、 二進法と十進法がごちゃ混ぜになってたりします。 よって、あなたがディスクを買った時に表記されていた容量よりも 実際の容量の方が小さいと考える前に、 まず十進法で(または単にバイト単位で)実際のサイズを計算してみてください。 <p> <!-- Concerning terminology and abbreviation for binary units, <htmlurl name="Knuth" url="http://www-cs-staff.stanford.edu/~knuth/"> has an alternative <htmlurl name="proposal" url="http://www-cs-staff.stanford.edu/~knuth/news.html">, namely to use KKB, MMB, GGB, TTB, PPB, EEB, ZZB, YYB and to call these <it>large kilobyte</it>, <it>large megabyte</it>, ... <it>large yottabyte</it>. He writes: `Notice that doubling the letter connotes both binary-ness and large-ness.' This is a good proposal - `large gigabyte' sounds better than `gibibyte'. For our purposes however the only important thing is to stress that a megabyte has precisely 1000000 bytes, and that some other term and abbreviation is required if you mean something else. --> 二進数単位の専門用語や省略形に関しては、 <htmlurl name="Knuth" url="http://www-cs-staff.stanford.edu/~knuth/"> に <htmlurl name="代案" url="http://www-cs-staff.stanford.edu/~knuth/news.html"> があります。 KKB, MMB, GGB, TTB, PPB, EEB, ZZB, YYB と記述して、 <it>ラージ キロバイト(large kilobyte)</it>, <it>ラージ メガバイト(large megabyte)</it>, ... <it>ラージ ヨタバイト(large yottabyte(</it> と読むというものです。 彼はこのように書いています: 「文字を二重にしているのは、二進数という性質と、 (訳注: 10進数での値より)大きい性質を暗示しているのです」 これはよい提案です - 「ラージギガバイト (large gigabyte)」は 「ギビバイト (gibibyte)」より発音しやすいですから。 しかしながら、我々の目的のためにただ一つ重要なことは、 メガバイト (megabyte) がちょうど 1000000 バイトであることを強調することで、 もし何か他のことを意味するのならば他の用語や省略形が必要であるということです。 <sect1> <!-- Sectorsize --> セクタサイズ <p> <nidx>disk!sectorsize</nidx> <!-- In the present text a sector has 512 bytes. This is almost always true, but for example certain MO disks use a sectorsize of 2048 bytes, and all capacities given below must be multiplied by four. (When using <tt/fdisk/ on such disks, make sure you have version 2.9i or later, and give the `-b 2048' option.) --> この文書ではセクタは 512 バイトです。これは大抵の場合は真ですが、 いくらかの MO ディスクは 2048 バイトのセクタサイズを使用しているので (訳注: 640MB や 1.3GB(GIGAMO) の 3.5 インチ MO・PD・DVD-RAM などが該当します)、 以下の説明においては実際の容量は 4倍にして考える必要があります。 (このようなディスクに <tt/fdisk/ を使用する時は、 バージョン 2.9i かそれ以降を使用し、 `-b 2048' オプションを与えなければなりません) <sect1> <!-- Disksize --> ディスクサイズ <p> <nidx>disk!disksize</nidx> <!-- A disk with C cylinders, H heads and S sectors per track has C<tt/*/H<tt/*/S sectors in all, and can store C<tt/*/H<tt/*/S<tt/*/512 bytes. For example, if the disk label says C/H/S=4092/16/63 then the disk has 4092<tt/*/16<tt/*/63=4124736 sectors, and can hold 4124736<tt/*/512=2111864832 bytes (2.11 GB). There is an industry convention to give C/H/S=16383/16/63 for disks larger than 8.4 GB, and the disk size can no longer be read off from the C/H/S values reported by the disk. --> C シリンダ、H ヘッド、S セクタ毎トラックのディスクは、 全体で C*H*S セクタを持ち、C*H*S*512 バイトを格納することができます。 例えば、ディスクのラベルに C/H/S=4092/16/63 と書かれていたら、 このディスクは 4092*16*63=4124736 セクタを持ち、 4124736*512=2111864832 バイト (2.11 GB) を格納することができます。 8.4GB より大容量なディスクには C/H/S=16383/16/63 を与えるという工業規格 (industry convention) があるので、 そのようなディスクのサイズはもはやディスクから報告された C/H/S 値からは 読み取ることはできません。 <sect> <!-- Disk Access --> ディスクアクセス <p> <!-- In order to read or write something from or to the disk, we have to specify a position on the disk, for example by giving a sector or block number. If the disk is a SCSI disk, then this sector number goes directly into the SCSI command and is understood by the disk. If the disk is an IDE disk using LBA, then precisely the same holds. But if the disk is old, RLL or MFM or IDE from before the LBA times, then the disk hardware expects a triple (cylinder,head,sector) to designate the desired spot on the disk. --> ディスクに対して何かを読み書きするためには、 例えばセクタやブロックの番号を与えるなどの方法で、 ディスク上の位置を指定する必要があります。 ディスクが SCSI ディスクの場合は このセクタ番号は直接 SCSI コマンドにすることができ、 ディスクはそれを理解します。 ディスクが IDE ディスク で LBA を使用している場合は SCSI の場合とまさに同じ方法です。 しかしディスクが古く、RLL や MFM や、LBA 時代以前の IDE だったりする場合は、 ディスク上の希望の位置を指定するために、 ディスクのハードウェアは(シリンダ、ヘッド、セクタの)三つの値を要求します。 <p> <!-- The correspondence between the linear numbering and this 3D notation is as follows: for a disk with C cylinders, H heads and S sectors/track position (c,h,s) in 3D or CHS notation is the same as position c<tt/*/H<tt/*/S + h<tt/*/S + (s-1) in linear or LBA notation. (The minus one is because traditionally sectors are counted from 1, not 0, in this 3D notation.) --> リニアナンバリングとこの三次元表記の対応は次のようになっています: C シリンダ H ヘッド S セクタ毎トラックを持つディスクにとって、 三次元または CHS 表記による位置 (c,h,s) は、 リニアまたは LBA 表記による位置 c*H*S + h*S + (s-1) と同じです。 (マイナス 1 する理由は、 この三次元表記では伝統的に 0 ではなく 1 からセクタを数え始めるからです) <p> <!-- Consequently, in order to access a very old non-SCSI disk, we need to know its <em/geometry/, that is, the values of C, H and S. --> それゆえ、とても古い非 SCSI ディスクにアクセスするためには、 その<em/ジオメトリ/、つまり C,H,S という値を知っている必要があります。 <sect1> <!-- BIOS Disk Access and the 1024 cylinder limit --> BIOS によるディスクアクセスと 1024 シリンダ制限 <p> <!-- Linux does not use the BIOS, but some other systems do. The BIOS, which predates LBA times, offers with INT13 disk I/O routines that have (c,h,s) as input. (More precisely: <tt/AH/ selects the function to perform, <tt/CH/ is the low 8 bits of the cylinder number, <tt/CL/ has in bits 7-6 the high two bits of the cylinder number and in bits 5-0 the sector number, <tt/DH/ is the head number, and <tt/DL/ is the drive number (80h or 81h). This explains part of the layout of the partition table.) --> Linux は BIOS を使っていませんが、いくつかの他のシステムは使っています。 LBA 時代以前の BIOS は、入力として (c,h,s) を要求する INT13 というディスク I/O ルーチンを提供していました。 (より正確にいうと、<tt/AH/ (レジスタ)で実行するファンクションを、 <tt/CH/ でシリンダ数の下位 8ビットを、 <tt/CL/ の 7-6 ビットでシリンダ数の上位 2ビットを、5-0ビットでセクタ数を、 <tt/DH/ でヘッド数を、 そして <tt/DL/ でドライブナンバー(80h か 81h)を指定します。 これはパーティションテーブルの設計の章で説明しています。) <p> <!-- Thus, we have CHS encoded in three bytes, with 10 bits for the cylinder number, 8 bits for the head number, and 6 bits for the track sector number (numbered 1-63). It follows that cylinder numbers can range from 0 to 1023 and that no more than 1024 cylinders are BIOS addressable. --> かくして、10 ビットのシリンダ数、8 ビットのヘッド数、 そして 6 ビットのトラックセクタ数(1-63 の値をとる)からなる 3 バイトに CHS はエンコードされます。 つまりシリンダ数は 0 から 1023 の値をとることができ、 1024 シリンダより上は BIOS では表現できないということになります。 <p> <!-- DOS and Windows software did not change when IDE disks with LBA support were introduced, so DOS and Windows continued needing a disk geometry, even when this was no longer needed for the actual disk I/O, but only for talking to the BIOS. This again means that Linux needs the geometry in those places where communication with the BIOS or with other operating systems is required, even on a modern disk. --> DOS や Windows (訳注: Windows95 以前の Windows 3.1 等)といったソフトウェアは、 LBA をサポートした IDE ディスクが導入された時にも変更されませんでしたので、 ディスクジオメトリを必要とし続けました。 それは、(LBA を使った) 実際のディスク I/O の際には(ジオメトリは) もはや必要でないにも関わらず、 BIOS を通じてのみディスク I/O を行っていたからです。 これはさらに、今時のディスクを使っていても、 BIOS と会話するような場合や他の OS が必要とする場合には、 Linux もジオメトリを必要とすることを意味します。 <p> <!-- This state of affairs lasted for four years or so, and then disks appeared on the market that could not be addressed with the INT13 functions (because the 10+8+6=24 bits for (c,h,s) can address not more than 8.5 GB) and a new BIOS interface was designed: the so-called Extended INT13 functions, where DS:SI points at a 16-byte Disk Address Packet that contains an 8-byte starting absolute block number. --> この状態は 4年くらい前まで続いていて、 INT13 ファンクションで扱えないサイズのディスク (つまり (c,h,s) のための 10+8+6=24ビットでは 8.5GB 以上を扱えない) が市場に登場し、新しい BIOS インターフェースがデザインされました。 それは拡張 INT13 ファンクションと呼ばれ、 絶対ブロック数で始まる 8バイトを含む 16バイトのディスクアドレスパケットを DS:SI が指すというものです。 <p> <!-- Very slowly the Microsoft world is moving towards using these Extended INT13 functions. Probably a few years from now no modern system on modern hardware will need the concept of `disk geometry' anymore. --> Microsoft の世界がこれらの拡張 INT13 ファンクションに移行するのは 非常に遅いです (訳注: Windows95 以降では対応しています)。 おそらく「ディスクジオメトリ」というコンセプトはあと数年は必要でしょう。 <sect1> <!-- History of BIOS and IDE limits --> BIOS と IDE の「壁」(上限)の歴史 <p> <descrip> <!-- <tag/ATA Specification (for IDE disks) - the 137 GB limit/ At most 65536 cylinders (numbered 0-65535), 16 heads (numbered 0-15), 255 sectors/track (numbered 1-255), for a maximum total capacity of 267386880 sectors (of 512 bytes each), that is, 136902082560 bytes (137 GB). This is not yet a problem (in 1999), but will be a few years from now. --> <tag/ATA 仕様書 (IDE ディスク用) - 137 GB まで/ 65536 シリンダ (0-65535 の範囲)、16 ヘッド (0-15 の範囲)、 255 セクタ毎トラック (1-255 の範囲) まで扱えます。 よって最大で 267386880 セクタの容量があり(512 バイト単位で)、 136902082560 バイト (137 GB) になります。 これは(西暦1999年の時点では)まだ問題とはなっていませんが、 あと数年もしたら問題になるかもしれません。 <p> <!-- <tag/BIOS Int 13 - the 8.5 GB limit/ At most 1024 cylinders (numbered 0-1023), 256 heads (numbered 0-255), 63 sectors/track (numbered 1-63) for a maximum total capacity of 8455716864 bytes (8.5 GB). This is a serious limitation today. It means that DOS cannot use present day large disks. --> <tag/BIOS Int 13 - 8.5 GB まで/ 1024 シリンダ (0-1023 の範囲), 256 ヘッド (0-255 の範囲), 63 セクタ毎トラック (1-63 の範囲) まで扱えます。 よって最大で 8455716864 バイト (8.5 GB) になります。 これは今日では深刻な制限で、 DOS では今日の大容量ディスクが使えないことを意味しています。 <p> <!-- <tag/The 528 MB limit/ If the same values for c,h,s are used for the BIOS Int 13 call and for the IDE disk I/O, then both limitations combine, and one can use at most 1024 cylinders, 16 heads, 63 sectors/track, for a maximum total capacity of 528482304 bytes (528MB), the infamous 504 MiB limit for DOS with an old BIOS. This started being a problem around 1993, and people resorted to all kinds of trickery, both in hardware (LBA), in firmware (translating BIOS), and in software (disk managers). The concept of `translation' was invented (1994): a BIOS could use one geometry while talking to the drive, and another, fake, geometry while talking to DOS, and translate between the two. --> <tag/528 MB の壁/ BIOS Int 13 コールと IDE ディスク I/O の両方に同じ c,h,s の値を使った場合、 両方の制限が組み合わされ、 1024 シリンダ・16 ヘッド・63 セクタ毎トラックまでしか使用できず、 最大容量は 528482304 バイト (528MB) となります。 これが DOS と古い BIOS の組み合わせによる悪名高い 504MiB の壁です。 これは 1993年ごろに問題となり、人々はすべての種類のぺてんに訴えました。 すなわちハードウェア(LBA)、ファームウェア(BIOSによる変換)、 そしてソフトウェア(ディスクマネージャ)です。 「変換」の概念は 1994年にでっちあげられました: BIOS は、ドライブと会話する時のジオメトリと、それとは異なる、偽の、 DOS と会話する時のジオメトリを使い、そしてその 2つの間で変換を行います。 <p> <!-- <tag/The 2.1 GB limit (April 1996)/ Some older BIOSes only allocate 12 bits for the field in CMOS RAM that gives the number of cylinders. Consequently, this number can be at most 4095, and only 4095<tt/*/16<tt/*/63<tt/*/512=2113413120 bytes are accessible. The effect of having a larger disk would be a hang at boot time. This made disks with geometry 4092/16/63 rather popular. And still today many large disk drives come with a jumper to make them appear 4092/16/63. See also <htmlurl url="http://www.firmware.com/support/bios/over2gb.htm" name="over2gb.htm">. <htmlurl name="Other BIOSes" url="http://www.asus.com/Products/Techref/Ide/Intel/intel-ide-001.html"> would not hang but just detect a much smaller disk, like 429 MB instead of 2.5 GB. --> <tag/2.1GB の壁 (1996年 4月)/ いくつかの古い BIOS では、シリンダ数を格納するための CMOS RAM 内の フィールドを 12 ビット分しか確保していません。 そのため、この数字は最大でも 4095 以下となり、 たった 4095*16*63*512=2113413120 バイトしかアクセスできなくなります。 大容量ディスクを接続した時に、ブート時にハングしたりするという影響が出ます。 この制限によって、 かえって 4092/16/63 というジオメトリを持つディスクが一般的になりました。 そして今日でも、多くのディスクドライブが 4092/16/63 に見せかけるための ジャンパを持っています。 <htmlurl url="http://www.firmware.com/support/bios/over2gb.htm" name="over2gb.htm"> も参照してください。 <htmlurl name="その他の BIOS" url="http://www.asus.com/Products/Techref/Ide/Intel/intel-ide-001.html"> はハングはしませんが、2.5 GB の代わりに 429 MB といったように 非常に小容量なディスクとして検出してしまいます。 (訳注: つまりこの例では、上記の 2113413120 で割った剰余が ディスクの総容量として検出されているわけです) <p> <!-- <tag/The 3.2 GB limit/ There was a bug in the Phoenix 4.03 and 4.04 BIOS firmware that would cause the system to lock up in the CMOS setup for drives with a capacity over 3277 MB. See <htmlurl url="http://www.firmware.com/support/bios/over3gb.htm" name="over3gb.htm">. --> <tag/3.2 GB の壁/ これは Phoenix BIOS ファームウェアの 4.03 と 4.04 のバグで、 3277 MB を越える容量のドライブを繋いで CMOS セットアップを行うと システムがロックしてしまいます。 <htmlurl url="http://www.firmware.com/support/bios/over3gb.htm" name="over3gb.htm"> を参照してください。 <p> <!-- <tag/The 4.2 GB limit (Feb 1997)/ Simple BIOS translation (ECHS=Extended CHS, sometimes called `Large disk support' or just `Large') works by repeatedly doubling the number of heads and halving the number of cylinders shown to DOS, until the number of cylinders is at most 1024. Now DOS and Windows 95 cannot handle 256 heads, and in the common case that the disk reports 16 heads, this means that this simple mechanism only works up to 8192<tt/*/16<tt/*/63<tt/*/512=4227858432 bytes (with a fake geometry with 1024 cylinders, 128 heads, 63 sectors/track). Note that ECHS does not change the number of sectors per track, so if that is not 63, the limit will be lower. See <htmlurl url="http://www.firmware.com/support/bios/over4gb.htm" name="over4gb.htm">. --> <tag/4.2 GB の壁 (1997年 2月)/ 単純な BIOS 変換 (ECHS=拡張(Extended)CHS、 しばしば `Large disk support' やあるいは単に `Large' と呼ばれます)は、 ヘッド数を 2倍しシリンダ数を半分にするという動作を、 DOS から見えるシリンダ数が 1024 以下になるまで繰り返します。 現在 DOS と Windows 95 は 256 ヘッダを扱えませんし、 一般的にディスクは 16 ヘッドであると答えるので、 これはつまりこの単純なメカニズムが 8192*16*63*512=4227858432 バイト(偽のジオメトリは 1024 シリンダ・128 ヘッド・63 セクタ/トラック) までしか動作しないことを意味します。 ECHS はセクタ毎トラックの数は変更しないことに注意してください。 そしてこれが 63 ではない場合は制限はもっときつくなります。 <htmlurl url="http://www.firmware.com/support/bios/over4gb.htm" name="over4gb.htm"> を参照してください。 <p> <!-- <tag/The 7.9 GB limit/ Slightly smarter BIOSes avoid the previous problem by first adjusting the number of heads to 15 (`revised ECHS'), so that a fake geometry with 240 heads can be obtained, good for 1024<tt/*/240<tt/*/63<tt/*/512=7927234560 bytes. --> <tag/7.9 GB の壁/ 最初にヘッド数を 15 に調整することで上記のような問題 (ECHS を復習してください)を避けることのできる少し賢い BIOS は、 それによって 240 ヘッドまでの偽のジオメトリを得ることができるので、 1024*240*63*512=7927234560 バイトまで有効となります。 <p> <!-- <tag/The 8.4 GB limit/ <label id="The 8.4 GB limit"> Finally, if the BIOS does all it can to make this translation a success, and uses 255 heads and 63 sectors/track (`assisted LBA' or just `LBA') it may reach 1024<tt/*/255<tt/*/63<tt/*/512=8422686720 bytes, slightly less than the earlier 8.5 GB limit because the geometries with 256 heads must be avoided. (This translation will use for the number of heads the first value H in the sequence 16, 32, 64, 128, 255 for which the total disk capacity fits in 1024<tt/*/H<tt/*/63<tt/*/512, and then computes the number of cylinders C as total capacity divided by (H<tt/*/63<tt/*/512).) --> <tag/8.4 GB の壁/ <label id="The 8.4 GB limit"> 最後に、BIOS が可能な限りの変換に成功し、 255 ヘッドと 63 セクタ毎トラックを使うと (`assisted LBA' あるいは単に `LBA' と呼ばれる)、 1024*255*63*512=8422686720 バイトまで到達できます。 8.5GB 制限のちょっと手前ですが、 これは 256 ヘッダのジオメトリを避けなければならないからです。 (この変換はまず、ディスク容量が 1024*H*63*512 に収まるようにヘッド数 H を 16, 32, 64,128, 255 から選び、 次に総容量を (H*63*512) で割ってシリンダ数 C を計算します。) <p> <!-- <tag/The 33.8 GB limit (August 1999)/ The next hurdle comes with a size over 33.8 GB. The problem is that with the default 16 heads and 63 sectors/track this corresponds to a number of cylinders of more than 65535, which does not fit into a short. Most BIOSes in existence today can't handle such disks. (See, e.g., <htmlurl name="Asus upgrades" url="http://www.asus.com/Products/Motherboard/bios_slot1.html"> for new flash images that work.) Linux kernels older than 2.2.14 / 2.3.21 need a patch. See <ref id="verylarge" name="IDE problems with 34+ GB disks"> below. --> <tag/33.8 GB の壁 (1999年 8月)/ <label id="biosupgrades"> 次のハードルは 33.8GB を越えるサイズで訪れました。 この問題は、デフォルトの 16 ヘッド 63 セクタ毎トラックでは、 シリンダ数が short int に納めることができない 65535 より大きい数になってしまうことです。 今日では、ほとんどの BIOS がそのようなディスクを扱えないでしょう。 (例えば正常に動作する新しいフラッシュ(ROM)のイメージを得るには <htmlurl name="Asus upgrades" url="http://www.asus.com/Products/Motherboard/bios_slot1.html"> を参照してください) 2.2.14 / 2.3.21 より古い Linux カーネルではパッチが必要です。 後述の <ref id="verylarge" name="34 GB 超のディスクにおける IDE の問題"> を参照してください。 </descrip> <!-- For another discussion of this topic, see <htmlurl url="http://www.maxtor.com/technology/q&a/30004.html" name="Breaking the Barriers">, and, with more details, <htmlurl url="http://www.maxtor.com/technology/whitepapers/63001.html" name="IDE Hard Drive Capacity Barriers">. Hard drives over 8.4 GB are supposed to report their geometry as 16383/16/63. This in effect means that the `geometry' is obsolete, and the total disk size can no longer be computed from the geometry. --> このトピックについてのその他の議論については、 <htmlurl url="http://www.maxtor.com/technology/q&a/30004.html" name="Breaking the Barriers"> を参照してください。 さらに詳細については、 <htmlurl url="http://www.maxtor.com/technology/whitepapers/63001.html" name="IDE Hard Drive Capacity Barriers"> を参照してください。 8.4 GB を越えるハードディスクは、 自分のジオメトリを 16383/16/63 と答えると思われます。 これは要するに「ジオメトリ」というものが時代遅れであることを意味し、 ディスクの総容量はもはやジオメトリからは計算できません。 <sect> <!-- Booting --> ブート <p> <nidx>booting!BIOS usage during</nidx> <nidx>disk!BIOS access during booting</nidx> <!-- When the system is booted, the BIOS reads sector 0 (known as the MBR - the Master Boot Record) from the first disk (or from floppy or CDROM), and jumps to the code found there - usually some bootstrap loader. These small bootstrap programs found there typically have no own disk drivers and use BIOS services. This means that a Linux kernel can only be booted when it is entirely located within the first 1024 cylinders. --> システムをブートすると、 BIOS は一台目のディスク(またはフロッピーや CDROM)からセクタ 0 (MBR - Master Boot Record として知られている)を読み出し、 そこにあるコード - 通常は何らかのブートストラップローダ - へジャンプします。 この小さなブートストラッププログラムは 普通はそれ自身のディスクドライバは持ってなく BIOS サービスを利用します。 これは、Linux カーネルが最初の 1024 シリンダ内に完全に収まっている時のみ ブート可能であることを意味します。 <p> <!-- This problem is very easily solved: make sure that the kernel (and perhaps other files used during bootup, such as LILO map files) are located on a partition that is entirely contained in the first 1024 cylinders of a disk that the BIOS can access - probably this means the first or second disk. --> この問題はとても簡単に解決できます: BIOS がアクセス可能なディスク - おそらく一台目か二台目のディスク - の最初の 1024 シリンダ内に完全に収まるパーティションに、 カーネル(と、LILO のマップファイルのようにもしかしたら ブートアップの最中に使用されるかもしれない他のファイル) を配置すればいいのです。 <p> <!-- Thus: create a small partition, say 10 MB large, so that there is room for a handful of kernels, making sure that it is entirely contained within the first 1024 cylinders of the first or second disk. Mount it on <tt>/boot</tt> so that LILO will put its stuff there. --> したがって、カーネル用の領域として 10 MB くらいの小さなパーティションを、 一台目か二台目のディスクの先頭から 1024 シリンダ内に完全に収まるように 作成してください。これを <tt>/boot</tt> としてマウントし、 LILO がここにカーネルを置くようにしてください。 <p> <!-- <sect1>LILO and the `linear' option <label id="linear"> <p> Another point is that the boot loader and the BIOS must agree as to the disk geometry. LILO asks the kernel for the geometry, but more and more authors of disk drivers follow the bad habit of deriving a geometry from the partition table, instead of telling LILO what the BIOS will use. Thus, often the geometry supplied by the kernel is worthless. In such cases it helps to give LILO the `<tt/linear/' option. The effect of this is that LILO does not need geometry information at boot loader install time (it stores linear addresses in the maps) but does the conversion of linear addresses at boot time. Why is this not the default? Well, there is one disadvantage: with the `linear' option, LILO no longer knows about cylinder numbers, and hence cannot warn you when part of the kernel was stored above the 1024 cylinder limit, and you may end up with a system that does not boot. --> <sect1>LILO と `linear' オプション <label id="linear"> <p> もう一つの注意点は、ブートローダと BIOS がディスクジオメトリについて 意見が一致している必要があることです。 LILO はジオメトリについてカーネルに問い合わせますが、 ディスクドライバの作者の大多数は、 BIOS が使用するであろう LILO が告げる値の代わりに、 パーティションテーブルからジオメトリを得るという悪い癖を受け継いでいます。 したがって、カーネルから供給されるジオメトリはしばしば役に立ちません。 このような場合、LILO に `<tt/linear/' オプションを与えましょう。 この効果は、ブートローダのインストール時に LILO がジオメトリ情報を必要とせず (マップ中にリニアアドレス(訳注: のうち下位 24bit)を格納する)、 しかしブート時にリニアアドレスを変換する、というものです。 何故これがデフォルトではないのでしょう? そうですね、一つ不具合があるのです: `linear' オプションを付けると、LILO はシリンダ数を知る必要がなくなり、 したがってカーネルの一部が 1024シリンダ制限を越えて格納されても 警告を出さなくなり、 しまいにはブートしないシステムが出来て終わる可能性があるのです。 <!-- <sect1>1024 cylinders is not 1024 cylinders<p> Tim Williams writes: `I had my Linux partition within the first 1024 cylinders and still it wouldnt boot. First when I moved it below 1 GB did things work.' How can that be? Well, this was a SCSI disk with AHA2940UW controller which uses either H=64, S=32 (that is, cylinders of 1 MiB = 1.05 MB), or H=255, S=63 (that is, cylinders of 8.2 MB), depending on setup options in firmware and BIOS. No doubt the BIOS assumed the former, so that the 1024 cylinder limit was found at 1 GiB, while Linux used the latter and LILO thought that this limit was at 8.4 GB. --> <sect1>1024 シリンダが 1024 シリンダではない<p> Tim Williams はこういってます: 「私は Linux のパーティションを最初の 1024 シリンダ以内に作成しましたが、 それでもなお起動しませんでした。1GB 以内に移動したらやっと動きました。」 どうしてなんでしょう? そう、これは AHA2940UW コントローラに接続された SCSI ディスクで、 このコントローラはファームウェアと BIOS の設定オプションに依存して H=64, S=32 (1シリンダは 1 MiB = 1.05 MB になる)か、 H=255, S=63 (1シリンダは 8.2 MB になる)のどちらか使用します。 間違いなく BIOS が前者の設定になっていて、 よって 1024 シリンダ制限が 1 GiB になっています。 しかし Linux が後者の値を使っている間は LILO は制限が 8.4GB であると思っているわけです。 <!-- 1/3 --> <sect> <!-- Disk geometry, partitions and `overlap' --> ディスクジオメトリ、パーティション、重複(overlap) <label id="overlap"> <p> <nidx>disk!geometry</nidx> <nidx>disk!partitions</nidx> <!-- If you have several operating systems on your disks, then each uses one or more disk partitions. A disagreement on where these partitions are may have catastrophic consequences. --> ディスク上にいくつかの OS が存在する場合、 それぞれの OS は一つかそれ以上のディスクパーティションを使用します。 これらのパーティションの不一致は破滅的な結果をもたらすことがあります。 <label id="partitiontable"> <!-- The MBR contains a <it>partition table</it> describing where the (primary) partitions are. There are 4 table entries, for 4 primary partitions, and each looks like --> MBR には(基本)パーティションがどこに存在するかを記述した <it>パーティションテーブル</it>が存在します。 4つの基本パーティションのために 4つのテーブルのエントリがあり、 それは以下のようになっています。 <!-- <tscreen><verb> struct partition { char active; /* 0x80: bootable, 0: not bootable */ char begin[3]; /* CHS for first sector */ char type; char end[3]; /* CHS for last sector */ int start; /* 32 bit sector number (counting from 0) */ int length; /* 32 bit number of sectors */ }; --> <tscreen><verb> struct partition { char active; /* 0x80: ブート可, 0: ブート不可 */ char begin[3]; /* 最初のセクタの CHS */ char type; char end[3]; /* 最後のセクタの CHS */ int start; /* 32 bit のセクタ番号 (0 から数え始める) */ int length; /* 32 bit のセクタ総数 */ }; </verb></tscreen> <!-- (where CHS stands for Cylinder/Head/Sector). --> (CHS は シリンダ/ヘッド/セクタを表します。) <!-- This information is redundant: the location of a partition is given both by the 24-bit <tt/begin/ and <tt/end/ fields, and by the 32-bit <tt/start/ and <tt/length/ fields. --> この情報は冗長です: 24ビットの <tt/begin/ および <tt/end/ フィールドによってと、 32ビットの <tt/start/ および <tt/length/ フィールドによっての両方で、 パーティションの位置が与えられています。 <!-- Linux only uses the <tt/start/ and <tt/length/ fields, and can therefore handle partitions of not more than 2^32 sectors, that is, partitions of at most 2 TiB. That is a hundred times larger than the disks available today, so maybe it will be enough for the next eight years or so. (So, partitions can be very large, but there is a serious restriction in that a file in an ext2 filesystem on hardware with 32-bit integers cannot be larger than 2 GiB.) --> Linux は <tt/start/ と <tt/length/ のフィールドのみを使用するので、 それゆえに 2^32 セクタまでのパーティションを取り扱うことができます。 つまり、2 TiB (= 2048 GiB) のパーティションです。 これは現在利用できるディスクの 100 倍くらい大きいので、 あと 8年間くらいは大丈夫でしょう。 (そう、パーティションは非常に大きくできます。 しかし深刻な制限があります。 自然な整数が 32bit のハードウェア(訳注: 例えば CPU が Intel x86 系統のマシン) 上の ext2 ファイルシステム上では、 2 GiB 以上のファイルは作成できないのです。) <!-- DOS uses the <tt/begin/ and <tt/end/ fields, and uses the BIOS INT13 call to access the disk, and can therefore only handle disks of not more than 8.4 GB, even with a translating BIOS. (Partitions cannot be larger than 2.1 GB because of restrictions of the FAT16 file system.) The same holds for Windows 3.11 and WfWG and Windows NT 3.*. --> DOS は <tt/begin/ と <tt/end/ フィールドを使用し、 ディスクアクセスのために BIOS INT13 コールを使用しますので、 BIOS 変換を使っても 8.4GB 以下のディスクしか制御できません。 (FAT16 ファイルシステムの制限により、 パーティションは 2.1GB より大きくできません。) 同じことが Windows 3.11・WfWG (Windows for WorkGroup)・ Windows NT 3.* にもいえます。 <!-- Windows 95 has support for the Extended INT13 interface, and uses special partition types (c, e, f instead of b, 6, 5) to indicate that a partition should be accessed in this way. When these partition types are used, the <tt/begin/ and <tt/end/ fields contain dummy information (1023/255/63). Windows 95 OSR2 introduces the FAT32 file system (partition type b or c), that allows partitions of size at most 2 TiB. --> Windows 95 は拡張 INT13 インターフェースをサポートしており、 パーティションをその方法でアクセスする必要があることを示すための 特別なパーティションタイプを使います(b, 6, 5 の代わりに c, e, f)。 これらのパーティションタイプが使われている場合、 <tt/begin/ と <tt/end/ フィールドにはダミーの情報 (1023/255/63) が格納されます。 Windows 95 OSR2 からは FAT32 ファイルシステム (パーティションタイプは b または c)が導入され、 2 TiB までのパーティションを作成できます。 <!-- What is this nonsense you get from <tt/fdisk/ about `overlapping' partitions, when in fact nothing is wrong? Well - there is something `wrong': if you look at the <tt/begin/ and <tt/end/ fields of such partitions, as DOS does, they overlap. (And that cannot be corrected, because these fields cannot store cylinder numbers above 1024 - there will always be `overlap' as soon as you have more than 1024 cylinders.) However, if you look at the <tt/start/ and <tt/length/ fields, as Linux does, and as Windows 95 does in the case of partitions with partition type c, e or f, then all is well. So, ignore these warnings when <tt/cfdisk/ is satisfied and you have a Linux-only disk. Be careful when the disk is shared with DOS. Use the commands <tt>cfdisk -Ps /dev/hdx</tt> and <tt>cfdisk -Pt /dev/hdx</tt> to look at the partition table of <tt>/dev/hdx</tt>. --> 実際には何も悪くないのに「重複(overlapping)」パーティションについて <tt/fdisk/ からたわごとを聞かされるのはなぜでしょう? やれやれ - 何か「悪い」のです: DOS がしているように、そのパーティションの <tt/begin/ と <tt/end/ フィールドを見た場合、それがオーバーラップしているのです。 (そしてそれは正しくありません。 なぜならそれらのフィールドは 1024 以上のシリンダ数を格納することができません - 1024 シリンダ以上の部分を使うと、 常にオーバーラップが発生するのです。) しかし、Linux や、パーティションタイプが c, e, f であるパーティションの場合に Windows 95 がしているように、 <tt/start/ と <tt/length/ フィールドを見る場合には、 それはまったく問題ありません。 そう、<tt/cfdisk/ が納得していて Linux でしかディスクを使わないのならば、 警告は無視してください。DOS と共有している場合は注意してください。 <tt>/dev/hdx</tt> のパーティションテーブルを見るには <tt>cfdisk -Ps /dev/hdx</tt> と <tt>cfdisk -Pt /dev/hdx</tt> コマンドを使ってください。。 <sect> <!-- Translation and Disk Managers --> 変換とディスクマネージャ <p> <nidx>disk!geometry translation</nidx> <nidx>BIOS!translating</nidx> <nidx>BIOS!LBA support</nidx> <!-- Disk geometry (with heads, cylinders and tracks) is something from the age of MFM and RLL. In those days it corresponded to a physical reality. Nowadays, with IDE or SCSI, nobody is interested in what the `real' geometry of a disk is. Indeed, the number of sectors per track is variable - there are more sectors per track close to the outer rim of the disk - so there is no `real' number of sectors per track. Quite the contrary: the IDE command INITIALIZE DRIVE PARAMETERS (91h) serves to tell the disk how many heads and sectors per track it is supposed to have today. It is quite normal to see a large modern disk that has 2 heads report 15 or 16 heads to the BIOS, while the BIOS may again report 255 heads to user software. --> (ヘッド数、シリンダ数、トラック数というような) ディスクジオメトリは MFM や RLL 時代の産物で、 当時は物理的なハードウェア構造を反映していました。 現在では、IDE でも SCSI でも、 ディスクの「本当の」ジオメトリについて興味を持つ人はいません。 実際のところ、1トラックあたりのセクタ数は可変で、 ディスクの外周の方がよりセクタ数が多くなっています。 つまり、一意に決まるような「本当の」 1トラックあたりのセクタ数というものは 存在しません。 それとはまるっきり反対に: IDE コマンド INITIALIZE DRIVE PARAMETERS (91h) は現在では、 ヘッド数と 1トラックあたりのセクタ数をどれだけ持っていることになっているかを ディスクに設定するために提供されています。 今時の大容量ディスクが実際にはヘッドを 2つしか持っていなくても BIOS に対しては 15 か 16 ヘッドであると報告したり、 また BIOS がユーザのソフトウェアに対して それをさらに 255 ヘッドだと報告したりするのは、ごく普通です。 <!-- For the user it is best to regard a disk as just a linear array of sectors numbered 0, 1, ..., and leave it to the firmware to find out where a given sector lives on the disk. This linear numbering is called LBA. --> ユーザーにとって最善なのは、 ディスク上にあたかも一直線にセクタ番号が並んでいる(0, 1, ...)として ディスク上のどこにセクタが存在するかといったことを ファームウェアに任せられることです。 このリニアナンバリングは LBA と呼ばれます。 <!-- So now the conceptual picture is the following. DOS, or some boot loader, talks to the BIOS, using (c,h,s) notation. The BIOS converts (c,h,s) to LBA notation using the fake geometry that the user is using. If the disk accepts LBA then this value is used for disk I/O. Otherwise, it is converted back to (c',h',s') using the geometry that the disk uses today, and that is used for disk I/O. --> 概念は以下の通りです。 DOS やいくつかのブートローダは (c,h,s) 表記を使って BIOS と会話します。 BIOS は、ユーザが使用する偽のジオメトリを使って (c,h,s) を LBA 表記に変換します。 ディスクが LBA を受け付ける場合は、この値をディスク I/O に使用します。 さもなければ、ディスクが使っているジオメトリを使って (c',h',s') に変換し直し、ディスク I/O に使います。 <!-- Note that there is a bit of confusion in the use of the expression `LBA': As a term describing disk capabilities it means `Linear Block Addressing' (as opposed to CHS Addressing). As a term in the BIOS Setup, it describes a translation scheme sometimes called `assisted LBA' - see above under `<ref id="The 8.4 GB limit">'. --> `LBA' という表現の使用におけるちょっとした混乱があることに注意してください: ディスクの性能を記述する用語としてならば `Linear Block Addressing' (CHS アドレッシングの逆)を意味します。BIOS 設定での用語としてならば、 しばしば `assisted LBA' と呼ばれる変換方式を意味します。 - 前述の `<ref id="The 8.4 GB limit" name="8.4 GB の壁">' を見てください。 <!-- Something similar works when the firmware doesn't speak LBA but the BIOS knows about translation. (In the setup this is often indicated as `Large'.) Now the BIOS will present a geometry (C,H,S) to the operating system, and use (C',H',S') while talking to the disk controller. Usually S = S', C = C'/N and H = H'<tt/*/N, where N is the smallest power of two that will ensure C' <= 1024 (so that least capacity is wasted by the rounding down in C' = C/N). Again, this allows access of up to 8.4 GB (7.8 GiB). --> (訳注: ハードディスクの)ファームウェアが LBA を理解しないけど、 BIOS がジオメトリ変換を利用できる場合は、似たようなことが起きます。 (BIOS 設定ではこれはしばしば `Large' と表示されます。) 今、BIOS が OS にジオメトリ (C,H,S) を示して、 ディスクコントローラと話す時に (C',H',S') を使うとします。 通常は S=S', C=C'/N, H=H'*N となります。 N は、C' <= 1024 となる最も小さい 2 の乗数です。 (これは、C' = C/N とする際の丸め(切捨て)によって無駄になる容量を 最小限にするためです。) さらに、この方法では 8.4GB (7.8 GiB) までアクセスできます。 <!-- (The third setup option usually is `Normal', where no translation is involved.) --> (BIOS の 三つ目の設定オプションは通常 `Normal' と呼ばれ、 どんな変換も行いません。) <!-- If a BIOS does not know about `Large' or `LBA', then there are software solutions around. Disk Managers like OnTrack or EZ-Drive replace the BIOS disk handling routines by their own. Often this is accomplished by having the disk manager code live in the MBR and subsequent sectors (OnTrack calls this code DDO: Dynamic Drive Overlay), so that it is booted before any other operating system. That is why one may have problems when booting from a floppy when a Disk Manager has been installed. --> BIOS で `Large' や `LBA' を利用できない場合は、 ソフトウェアによる解決方法もあります。 OnTrack や EZ-Drive のようなディスクマネージャは BIOS のディスク制御ルーチンを自分自身のものと置き換えます。 普通これは、ディスクマネージャのコードを MBR とそれに続くセクタ (OnTrack ではこのコードを DDO: Dynamic Drive Overlay と呼んでいます) に配置することで実現されており、他のすべての OS の前に起動されます。 ディスクマネージャがインストールされている所で、 OS をフロッピーから起動すると、何か問題があるかもしれません。 <!-- The effect is more or less the same as with a translating BIOS - but especially when running several different operating systems on the same disk, disk managers can cause a lot of trouble. --> ディスクマネージャの効果は多かれ少なかれ BIOS による変換と同じです - しかし特に、同じディスク上でいくつかの異なる OS を動作させると、 ディスクマネージャに由来する多くのトラブルが起きる可能性があります。 <!-- Linux does support OnTrack Disk Manager since version 1.3.14, and EZ-Drive since version 1.3.29. Some more details are given below. --> Linux は OnTrack Disk Manager のバージョン 1.3.14 からと、 EZ-Drive のバージョン 1.3.29 からをサポートしています。 詳細を以下に述べます。 <sect> <!-- Kernel disk translation for IDE disks --> IDEディスクのためのカーネルでのディスク変換 <p> <nidx>disk!translation done by kernel</nidx> <!-- If the Linux kernel detects the presence of some disk manager on an IDE disk, it will try to remap the disk in the same way this disk manager would have done, so that Linux sees the same disk partitioning as for example DOS with OnTrack or EZ-Drive. However, NO remapping is done when a geometry was specified on the command line - so a `<tt/hd=/<it/cyls/<tt/,/<it/heads/<tt/,/<it/secs/' command line option might well kill compatibility with a disk manager. --> Linux カーネルが IDE ディスク上に何らかのディスクマネージャの存在を 検出した場合、そのディスクマネージャがするのと同じ方法でディスクを 再マップしようとするので、Linux は例えば OnTrack や EZ-Drive を使っている DOS のように同じディスクパーティションを見ることになります。 しかし、ジオメトリが(訳注: LILOの)コマンドラインから指定された場合は 再マップは行われません - つまり `<tt/hd=/<it/cyls/<tt/,/<it/heads/<tt/,/<it/secs/' (訳注: `<tt/hdx=/<it/cyls/<tt/,/<it/heads/<tt/,/<it/secs/' が正しい) というコマンドラインオプションはディスクマネージャとの互換性を 失わせてしまいます。 <!-- The remapping is done by trying 4, 8, 16, 32, 64, 128, 255 heads (keeping H<tt/*/C constant) until either C <= 1024 or H = 255. --> 再マップは、C <= 1024 になるか H = 255 になるまで、 (H*C が一定であるように) ヘッド数(H)を 4, 8, 16, 32, 64, 128, 255 と増やしていきます。 <!-- The details are as follows - subsection headers are the strings appearing in the corresponding boot messages. Here and everywhere else in this text partition types are given in hexadecimal. --> 詳細は以下のようになります - 以下のサブセクションの題名はブートマネージャに対応すると思われる文字列です。 以降、パーティションタイプはすべて 16 進数であらわします。 <sect1>EZD<p> <nidx>disk!EZ-Drive translation</nidx> <nidx>disk!EZD translation</nidx> <!-- EZ-Drive is detected by the fact that the first primary partition has type 55. The geometry is remapped as described above, and the partition table from sector 0 is discarded - instead the partition table is read from sector 1. Disk block numbers are not changed, but writes to sector 0 are redirected to sector 1. This behaviour can be changed by recompiling the kernel with <tt/ #define FAKE_FDISK_FOR_EZDRIVE 0 / in <tt/ide.c/. --> 最初の基本パーティションタイプが 55 であるとき、 EZ-Drive が存在すると判断されます。 ジオメトリは上で説明したように変換され、 セクタ 0 にあるパーティションテーブルは無視されます。 その代わりに、パーティションテーブルはセクタ 1 から読み出されます。 ディスクのブロック番号は変更されませんが、セクタ 0への書き込みは、 セクタ 1 への書き込みに強制されます。 この振る舞いは、<tt/ide.c/ (訳注: カーネル 2.2.12 では <tt>drivers/block/ide.h</tt>) の中で <tt/ #define FAKE_FDISK_FOR_EZDRIVE 0 / としてカーネルを再構築すれば切り替えられます。 <sect1>DM6:DDO<p> <nidx>disk!OnTrack DiskManager translation</nidx> <nidx>disk!DM6:DD0 translation</nidx> <!-- OnTrack DiskManager (on the first disk) is detected by the fact that the first primary partition has type 54. The geometry is remapped as described above and the entire disk is shifted by 63 sectors (so that the old sector 63 becomes sector 0). Afterwards a new MBR (with partition table) is read from the new sector 0. Of course this shift is to make room for the DDO - that is why there is no shift on other disks. --> (一台目のドライブの)最初の基本パーティションタイプが 54 であると、 OnTrack ディスクマネージャが組み込まれていると判断されます。 ジオメトリはすでに述べた方法で変換され、 ディスク全体が 63 セクタ分ずらされます (つまり、元々のセクタ 63 はセクタ 0 と呼ばれることになります)。 この結果、新しい(パーティションテーブルを含む) MBR は、 新しいセクタ 0 から読み込まれます。 もちろん、このずらしは DDO のための空間を確保するためで、 これが一台目のディスク以外にはずらしが入らない理由です。 <sect1>DM6:AUX<p> <nidx>disk!OnTrack DiskManager translation</nidx> <nidx>disk!DM6:AUX</nidx> <!-- OnTrack DiskManager (on other disks) is detected by the fact that the first primary partition has type 51 or 53. The geometry is remapped as described above. --> (一台目のディスク以外の)基本パーティションがタイプ 51 か 53 のときには、 OnTrack ディスクマネージャが効いていると判断されます。 ジオメトリの変換は上に述べた通りです。 <sect1>DM6:MBR<p> <nidx>disk!OnTrack DiskManager translation</nidx> <nidx>disk!DM6:MBR</nidx> <!-- An older version of OnTrack DiskManager is detected not by partition type, but by signature. (Test whether the offset found in bytes 2 and 3 of the MBR is not more than 430, and the short found at this offset equals 0x55AA, and is followed by an odd byte.) Again the geometry is remapped as above. --> 古い OnTrack ディスクマネージャは、 パーティションタイプではなくシグネチャで検出されます。 (検出方法: MBR のバイト 2,3 にある数をオフセットと考え、 このオフセット値が430以下であるか確認します。 次にこのオフセット位置にある short int 値が 0x55AA で、 なおかつ、次の 1 バイトが奇数かどうかを監査します。) 変換方法は、上に述べた通りです。 <sect1>PTBL<p> <nidx>disk!PTBL translation</nidx> <!-- Finally, there is a test that tries to deduce a translation from the <tt/start/ and <tt/end/ values of the primary partitions: If some partition has start and end sector number 1 and 63, respectively, and end heads 31, 63, 127 or 254, then, since it is customary to end partitions on a cylinder boundary, and since moreover the IDE interface uses at most 16 heads, it is conjectured that a BIOS translation is active, and the geometry is remapped to use 32, 64, 128 or 255 heads, respectively. However, no remapping is done when the current idea of the geometry already has 63 sectors per track and at least as many heads (since this probably means that a remapping was done already). --> 最後に、基本パーティションの start と end の値から、 変換が行われてることを知る方法があることをご紹介しましょう。 もし、あるパーティションが <tt/start/ と <tt/end/ にそれぞれセクタ番号 1 と 63 を持っていて、さらに end のヘッド番号として 31, 63, 127, または 254 を持っているとすると、 パーティションの終わりはシリンダ境界におかれる慣習であること、 IDE インターフェースは最大 16 ヘッドであることから、 BIOS による変換がおこなわれていることが分かり、 また、ジオメトリはヘッド数 32, 64, 128, または 255 を使って 再マップされていることが分かります。 しかし、現在のジオメトリがすでにトラックあたり 63 セクタで、 たくさんのヘッドがあるというなら、変換は行いません (ヘッドがたくさんあるというのは、すでに変換が行われているということですから)。 <sect> <!-- Consequences --> 結論 <p> <nidx>disk!consequences of translation</nidx> <!-- What does all of this mean? For Linux users only one thing: that they must make sure that LILO and <tt/fdisk/ use the right geometry where `right' is defined for <tt/fdisk/ as the geometry used by the other operating systems on the same disk, and for LILO as the geometry that will enable successful interaction with the BIOS at boot time. (Usually these two coincide.) --> 結局どうだというのでしょう? Linux 利用者にとっては一点だけが重要です。 それは、LILO と <tt/fdisk/ が正しいジオメトリを使わなければならないことです。 ここでの「正しい」とは、<tt/fdisk/ に関しては同じディスク上の他の OS がそのジオメトリを使用しているという意味であり、 また LILO に関しては起動時に BIOS とやり取りして起動が成功する ジオメトリであるということです。(普通はこの 2つは一致します。) <!-- How does <tt/fdisk/ know about the geometry? It asks the kernel, using the <tt/HDIO_GETGEO/ ioctl. But the user can override the geometry interactively or on the command line. --> <tt/fdisk/ は、どうやってジオメトリを調べるのでしょう? <tt/HDIO_GETGEO/ ioctl を使用してカーネルに問い合わせるのです。 しかし、利用者は対話的に、あるいはコマンドラインからジオメトリを強制できます。 <!-- How does LILO know about the geometry? It asks the kernel, using the <tt/HDIO_GETGEO/ ioctl. But the user can override the geometry using the `<tt/disk=/' option in <tt>/etc/lilo.conf</tt> (see lilo.conf(5)). One may also give the <tt/linear/ option to LILO, and it will store LBA addresses instead of CHS addresses in its map file, and find out of the geometry to use at boot time (by using INT 13 Function 8 to ask for the drive geometry). --> LILO は、どうやってジオメトリを調べるのでしょう? <tt/HDIO_GETGEO/ ioctl を使用してカーネルに問い合わせるのです。 しかし、利用者は <tt>/etc/lilo.conf</tt> 内の "<tt/disk=/" オプションを使って、 ジオメトリを強制できます (lilo.conf(5) を参照してください)。 <tt/linear/ オプションを LILO に指定することもできます。 その場合、LILO は CHS アドレスの代わりに LBA アドレスをマップファイルに格納し、 起動するときにそれを使用します。 (ドライブのジオメトリを問い合わせるために INT 13 のファンクション 8 を使います) <!-- How does the kernel know what to answer? Well, first of all, the user may have specified an explicit geometry with a `<tt/hda=/<it/cyls/<tt/,/<it/heads/<tt/,/<it/secs/' kernel command line option (see bootparam(7)), perhaps by hand, or by asking the boot loader to supply such an option to the kernel. For example, one can tell LILO to supply such an option by adding an `<tt/append = "hda=/<it/cyls/<tt/,/<it/heads/<tt/,/<it/secs/<tt/"/' line in <tt>/etc/lilo.conf</tt> (see lilo.conf(5)). And otherwise the kernel will guess, possibly using values obtained from the BIOS or the hardware. --> カーネルは(<tt/fdisk/ や LILO に訊かれた)答をどうやって調べるのでしょうか? ええと、おそらく手動か、または カーネルにそのようなオプションを渡すように ブートローダに質問されて、 最初に利用者が `<tt/hda=/<it/cyls/<tt/,/<it/heads/<tt/,/<it/secs/' というカーネルコマンドラインオプション(bootparam(7) を参照のこと) によって明示的にこれを指定するかもしれません。 例えば、<tt>/etc/lilo.conf</tt> 内に `<tt/append = "hda=/<it/cyls/<tt/,/<it/heads/<tt/,/<it/secs/<tt/"/' というような行を追加することにより、 そのようなオプションを LILO に与えることができます(lilo.conf(5) を参照のこと)。 でなければ、カーネルは BIOS かハードウェアから取得した値を使って 何とかして推量するでしょう。 <!-- It is possible (since Linux 2.1.79) to change the kernel's ideas about the geometry by using the <tt>/proc</tt> filesystem. For example <tscreen><verb> # 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 # </verb></tscreen> --> (Linux 2.1.79 からは) <tt>/proc</tt> ファイルシステムを使用することによって ジオメトリについてのカーネルの見解を変更することが可能です。 例えばこんな感じです。 <tscreen><verb> # 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 # </verb></tscreen> <!-- <sect1> Computing LILO parameters <p> Sometimes it is useful to force a certain geometry by adding `<tt/hda=/<it/cyls/<tt/,/<it/heads/<tt/,/<it/secs/' on the kernel command line. Almost always one wants <it/secs/=63, and the purpose of adding this is to specify <it/heads/. (Reasonable values today are <it/heads/=16 and <it/heads/=255.) What should one specify for <it/cyls/? Precisely that number that will give the right total capacity of C*H*S sectors. For example, for a drive with 71346240 sectors (36529274880 bytes) one would compute C as 71346240/(255*63)=4441 (for example using the program <tt/bc/), and give boot parameter <tt/hdc=4441,255,63/. How does one know the right total capacity? For example, <tscreen><verb> # 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 </verb></tscreen> gives two ways of finding the total number of sectors 71346240. The kernel output <tscreen><verb> # dmesg | grep hdc ... hdc: Maxtor 93652U8, 34837MB w/2048kB Cache, CHS=70780/16/63 hdc: [PTBL] [4441/255/63] hdc1 hdc2 hdc3! hdc4 < hdc5 > ... </verb></tscreen> tells us about (at least) 34837*2048=71346176 and about (at least) 70780*16*63=71346240 sectors. In this case the second value happens to be precisely correct, but in general both may be rounded down. This is a good way to approximate the disk size when <tt/hdparm/ is unavailable. Never give a too large value for <it/cyls/! In the case of SCSI disks the precise number of sectors is given in the kernel boot messages: <tscreen><verb> SCSI device sda: hdwr sector= 512 bytes. Sectors= 17755792 [8669 MB] [8.7 GB] </verb></tscreen> (and MB, GB are rounded, not rounded down, and `binary'). --> <sect1> LILO のパラメータを計算する <p> カーネルのコマンドラインに `<tt/hda=/<it/cyls/<tt/,/<it/heads/<tt/,/<it/secs/' と追加することによって信頼できるジオメトリを強要するのは、時には便利です。 ほとんど大抵の場合は <it/secs/=63 にします。 それから <it/heads/ を指定します。 (今日での便利な値は <it/heads/=16 と <it/heads/=255 です) <it/cyls/ に指定すべき値は何でしょう? この値は C*H*S セクタの総容量から正確に求めることができます。 例えば 71346240 セクタ (36529274880 バイト)のドライブでは、 C は 71346240/(255*63)=4441 として計算でき (計算には <tt/bc/ プログラムを使えます)、 <tt/hdc=4441,255,63/ というブートパラメータを得ることができます。 どのようにして正確な総容量を知ることができるのでしょう? 例えば、 <tscreen><verb> # 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 </verb></tscreen> というようにトータルで 71346240 セクタであることを知る 2つの方法があります。 カーネルの出力 <tscreen><verb> # dmesg | grep hdc ... hdc: Maxtor 93652U8, 34837MB w/2048kB Cache, CHS=70780/16/63 hdc: [PTBL] [4441/255/63] hdc1 hdc2 hdc3! hdc4 < hdc5 > ... </verb></tscreen> は(少なくとも) 34837*2048=71346176 か(少なくとも) 70780*16*63=71346240 セクタであることを教えてくれます。 この場合では、2番目の値は (訳注: 上記 hdparm での値と) 偶然にもまったく同じですが、 一般的にこれらの値は端数が切り捨てられています。 これは <tt/hdparm/ が利用できない時にディスクサイズを概算するいい方法です。 決して <it/cyls/ に大きすぎる値を与えないように! SCSI ディスクの場合には、 正確なセクタ数はカーネルのブートメッセージに表示されます: <tscreen><verb> SCSI device sda: hdwr sector= 512 bytes. Sectors= 17755792 [8669 MB] [8.7 GB] </verb></tscreen> (MB や GB は丸められていますが、切り捨てられてはいません。 また 2進で計算しています) <!-- <sect>Details<p> <sect1>IDE details - the seven geometries<p> <nidx>disk!IDE geometry setting</nidx> The IDE driver has five sources of information about the geometry. The first (G_user) is the one specified by the user on the command line. The second (G_bios) is the BIOS Fixed Disk Parameter Table (for first and second disk only) that is read on system startup, before the switch to 32-bit mode. The third (G_phys) and fourth (G_log) are returned by the IDE controller as a response to the IDENTIFY command - they are the `physical' and `current logical' geometries. --> <sect>詳細<p> <sect1>IDE の詳細 - 7つのジオメトリ<p> <nidx>disk!IDE geometry setting</nidx> IDE ドライバはジオメトリに関する 5 つの情報源を持っています。 一つ目 (G_user) はコマンドラインでユーザによって指定されたもの。 二つ目 (G_bios) は BIOS の Fixed Disk Parameter Table (一台目と二台目のディスクに限る) で、 32 ビットモードに移行する前のシステム起動時に読み込まれます。 三つ目 (G_phys) と四つ目 (G_log) は IDENTIFY DEVICE コマンドに対して IDE コントローラが答える情報で、それぞれ「物理」「現状の論理」ジオメトリです。 <!-- On the other hand, the driver needs two values for the geometry: on the one hand G_fdisk, returned by a <tt/HDIO_GETGEO/ ioctl, and on the other hand G_used, which is actually used for doing I/O. Both G_fdisk and G_used are initialized to G_user if given, to G_bios when this information is present according to CMOS, and to G_phys otherwise. If G_log looks reasonable then G_used is set to that. Otherwise, if G_used is unreasonable and G_phys looks reasonable then G_used is set to G_phys. Here `reasonable' means that the number of heads is in the range 1-16. --> 一方、ドライバはジオメトリとして二つの値を必要とします。 一つ (G_fdisk) は <tt/HDIO_GETGEO/ ioctl が返す値、 もう一つ (G_used) は I/O を行う際に実際に使用される値です。 G_user が与えられていれば、 G_fdisk と G_used はそれで初期化されます。 G_user が与えられず、CMOS から情報 (G_bios) が取得できれば、 それに設定されます。それ以外のときには、G_phys に設定されます。 G_log が妥当であるようなら、G_used はそれに設定されます。 あるいは、G_used の値が妥当ではなく、G_phys が妥当であるようなら、 G_used には G_phys の値が設定されます。 ここでの「妥当」とは、ヘッド数が 1-16 の範囲に入っていることです。 <!-- To say this in other words: the command line overrides the BIOS, and will determine what <tt/fdisk/ sees, but if it specifies a translated geometry (with more than 16 heads), then for kernel I/O it will be overridden by output of the IDENTIFY command. --> 言い換えると、コマンドラインでの指定は、BIOS からの値を上書きして <tt/fdisk/ がどのようにディスクをとらえるかを決めます。 しかし、もし、(ヘッドが 16 を超える)変換後のジオメトリを指定すると カーネル I/O ではその値は破棄され、IDENTIFY DEVICE コマンドからの値が使用されます。 <!-- Note that G_bios is rather unreliable: for systems booting from SCSI the first and second disk may well be SCSI disks, and the geometry that the BIOS reported for sda is used by the kernel for hda. Moreover, disks that are not mentioned in the BIOS Setup are not seen by the BIOS. This means that, e.g., in an IDE-only system where hdb is not given in the Setup, the geometries reported by the BIOS for the first and second disk will apply to hda and hdc. --> G_bios はそんなに信用できないことに注意してください: SCSI からシステムを起動するために一台目と二台目のディスクが SCSI ディスクだったとしても、 sda のために BIOS が報告するジオメトリはカーネルでは hda のために使われます。 そのうえ、BIOS セットアップで認識させていないディスクは BIOS からは見えません。これは次のようなことを意味します。 例えば、BIOS セットアップで hdb が認識されていない IDE オンリーのシステムでは、一台目と二台目のディスクについて BIOS が報告するジオメトリは hda と hdc のものでしょう。 (訳注: つまりディスク hdb に対して、 hdc のジオメトリが適用されるということです。) <!-- <sect1>SCSI details<p> <nidx>disk!SCSI geometry setting</nidx> The situation for SCSI is slightly different, as the SCSI commands already use logical block numbers, so a `geometry' is entirely irrelevant for actual I/O. However, the format of the partition table is still the same, so <tt/fdisk/ has to invent some geometry, and also uses <tt/HDIO_GETGEO/ here - indeed, <tt/fdisk/ does not distinguish between IDE and SCSI disks. As one can see from the detailed description below, the various drivers each invent a somewhat different geometry. Indeed, one big mess. --> <sect1>SCSI に関する詳細<p> <nidx>disk!SCSI geometry setting</nidx> SCSI での事態は少し違っていて、 SCSI コマンドは既に論理ブロック番号を使っているので、 ジオメトリは実際の I/O に関してはまったく不適切なものです。 しかし、パーティションテーブルのフォーマットは未だに IDE と同じなので、 fdisk はいくつかのジオメトリをでっち上げなければならず、 また <tt/HDIO_GETGEO/ も使わなければなりません - 確かに、<tt/fdisk/ は IDE ディスクであろうが SCSI ディスクであろうが区別はしません。 以下の詳細な記述を読めば、種々のドライバがそれぞれ、 ちょっとずつ異なったジオメトリをでっち上げるのが分かります。 本当に困ったもんだ。 <p> <!-- If you are not using DOS or so, then avoid all extended translation settings, and just use 64 heads, 32 sectors per track (for a nice, convenient 1 MiB per cylinder), if possible, so that no problems arise when you move the disk from one controller to another. Some SCSI disk drivers (aha152x, pas16, ppa, qlogicfas, qlogicisp) are so nervous about DOS compatibility that they will not allow a Linux-only system to use more than about 8 GiB. This is a bug. --> DOS やその類を使わないのならば、すべての拡張変換設定を避けて、 64 ヘッド 32 セクタ毎トラックを使ってください (これだと 1 MiB/シリンダとなりとても便利です)。 またこれならば、ディスクをあるコントローラから他のコントローラに 繋ぎ換えても問題は起きないでしょう。 いくつかの SCSI ディスクドライバ(aha152x, pas16, ppa, qlogicfas, qlogicisp)は DOS との互換性にとても神経質で、 Linux のみのシステムでも 8 GiB を越えるディスクの使用を許してくれないでしょう。 これはバグです。 <p> <!-- What is the real geometry? The easiest answer is that there is no such thing. And if there were, you wouldn't want to know, and certainly NEVER, EVER tell <tt/fdisk/ or LILO or the kernel about it. It is strictly a business between the SCSI controller and the disk. Let me repeat that: only silly people tell <tt/fdisk//LILO/kernel about the true SCSI disk geometry. --> 本当のジオメトリはどうなっているのでしょう? それは簡単、そんなものはありません。 多分知りたくもないでしょうが、まぁ、そんなものがあったとしても <em/絶対に/ <em/決して/ <tt/fdisk/ や LILO やカーネルに そんなものを指定しないでください。 ジオメトリは SCSI コントローラとディスクの間でだけ使うべきものです。 くどいようですが、 SCSI ディスクのジオメトリを <tt/fdisk/ や LILO やカーネルに指定するような奴は阿呆だけです。 <p> <!-- But if you are curious and insist, you might ask the disk itself. There is the important command READ CAPACITY that will give the total size of the disk, and there is the MODE SENSE command, that in the Rigid Disk Drive Geometry Page (page 04) gives the number of cylinders and heads (this is information that cannot be changed), and in the Format Page (page 03) gives the number of bytes per sector, and sectors per track. This latter number is typically dependent upon the notch, and the number of sectors per track varies - the outer tracks have more sectors than the inner tracks. The Linux program <tt/scsiinfo/ will give this information. There are many details and complications, and it is clear that nobody (probably not even the operating system) wants to use this information. Moreover, as long as we are only concerned about <tt/fdisk/ and LILO, one typically gets answers like C/H/S=4476/27/171 - values that cannot be used by <tt/fdisk/ because the partition table reserves only 10 resp. 8 resp. 6 bits for C/H/S. --> それでも好奇心のあまりどうしてもと言い張るのであれば、 ディスク自身に問い合わせることができます。 SCSI コマンドには、総容量を調べる READ CAPACITY コマンドがあります。 また、MODE SENSE コマンドの Rigid Disk Drive Geometry ページ(ページ04) はシリンダ数とヘッド数を教えてくれ(変更はできません)、 Format ページ(ページ03)はセクタあたりのバイト数とトラックあたりの セクタ数を教えてくれます。後者は普通ノッチに依存します。 つまり、トラックあたりのセクタ数は可変でして、 外側のトラックには内側よりたくさんのセクタが入っています。 Linux の <tt/scsiinfo/ プログラムはこういった情報を教えてくれます。 こういった情報は詳細を極めた上に複雑この上なく、 おまけに明らかに誰も(多分 OS ですら)こんな情報は使いません。 その上、<tt/fdisk/ と LILO に関する限り、 普通に返される C/H/S = 4476/27/171 などという値は使い物になりません。 というのは、パーティションテーブルは C/H/S に 10/8/6 ビットづつしか割り当てていないからです。 (訳注：原著者に問い合わせたところ、ノッチとは「一つのディスクの中で、 トラックあたりのセクタ数が同じ領域」とのことです。) <p> <!-- Then where does the kernel <tt/HDIO_GETGEO/ get its information from? Well, either from the SCSI controller, or by making an educated guess. Some drivers seem to think that we want to know `reality', but of course we only want to know what the DOS or OS/2 FDISK (or Adaptec AFDISK, etc) will use. --> では、カーネルは <tt/HDIO_GETGEO/ のための情報をどこから持ってくるのでしょう? これは SCSI コントローラから持ってくるか、何らかの賢い方法で作ってしまいます。 ドライバによっては我々が「真実」を欲しがっていると考えているようですが、 どっこい、我々は DOS や OS/2 の FDISK (や、Adaptec の AFDISK なんか) が使う数字が欲しいだけです。 <p> <!-- Note that Linux <tt/fdisk/ needs the numbers H and S of heads and sectors per track to convert LBA sector numbers into c/h/s addresses, but the number C of cylinders does not play a role in this conversion. Some drivers use (C,H,S) = (1023,255,63) to signal that the drive capacity is at least 1023<tt/*/255<tt/*/63 sectors. This is unfortunate, since it does not reveal the actual size, and will limit the users of most <tt/fdisk/ versions to about 8 GiB of their disks - a real limitation in these days. --> Linux の <tt/fdisk/ は H と S つまり、 ヘッド数とトラックあたりのセクタ数だけを使って LBA を C/H/S アドレスに変換しますが、シリンダ数 C は使用しないことに注意してください。 ドライバによっては、ドライバが 1023*255*63 セクタに対応できることを知らせるために、 (C,H,S) = (1023,255,63) であると報告してきます。不幸なことに、これからは実際の容量はわかりませんし、 <tt/fdisk/ のほとんどの版で、取り扱える容量を 8 GiB に限定してしまいます。 これは、今日の実際の上限となっています。 <p> <!-- In the description below, M denotes the total disk capacity, and C, H, S the number of cylinders, heads and sectors per track. It suffices to give H, S if we regard C as defined by M / (H<tt/*/S). --> 以下の記述では、M をディスクの総容量、C,H,S をシリンダ、ヘッド、 トラックあたりのセクタ数とします。 C を M / (H*S) で定義されると考えるなら、H,S を得るだけで十分です。 <p> <!-- By default, H=64, S=32. --> H=64, S=32 を初期値とします。 <p> <descrip> <tag/aha1740, dtc, g_NCR5380, t128, wd7000:/ <p> <!-- H=64, S=32. --> H=64, S=32 です。 <p> <tag/aha152x, pas16, ppa, qlogicfas, qlogicisp:/ <p> <!-- H=64, S=32 unless C > 1024, in which case H=255, S=63, C = min(1023, M/(H<tt/*/S)). (Thus C is truncated, and H<tt/*/S<tt/*/C is not an approximation to the disk capacity M. This will confuse most versions of <tt/fdisk/.) The <tt/ppa.c/ code uses M+1 instead of M and says that due to a bug in <tt/sd.c/ M is off by 1. --> C > 1024 になるまでは、H=64, S=32。 それ以降は、H=255, S=63, C = min(1023, M/(H*S))。 (このため、C は丸められており、 H*S*Cはディスクの総容量 M とはなりません。 これは、たいていの版の <tt/fdisk/ で問題となります)。 <tt/ppa.c/ のコードでは、M ではなく、M+1 を使用しており、 <tt/sd.c/ のバグにより、 M は 1 のオフセットを持っていると書かれています。 <p> <tag/advansys:/ <p> <!-- H=64, S=32 unless C > 1024 and moreover the `> 1 GB' option in the BIOS is enabled, in which case H=255, S=63. --> C > 1024 になるまでは、H=64, S=32。 それ以降は BIOS の `> 1 GB' オプションが入っていれば H=255, S=63 です。 <p> <tag/aha1542:/ <p> <!-- Ask the controller which of two possible translation schemes is in use, and use either H=255, S=63 or H=64, S=32. In the former case there is a boot message "aha1542.c: Using extended bios translation". --> コントローラに 2 つの内のどちらの変換方法を用いているか問いあわせ、 H=255, S=63 か、H=64, S=32 の何れかを使用します。 前者を使っている場合は、起動メッセージとして "aha1542.c: Using extended bios translation" と表示されます。 <p> <tag/aic7xxx:/ <p> <!-- H=64, S=32 unless C > 1024, and moreover either the "extended" boot parameter was given, or the `extended' bit was set in the SEEPROM or BIOS, in which case H=255, S=63. In Linux 2.0.36 this extended translation would always be set in case no SEEPROM was found, but in Linux 2.2.6 if no SEEPROM is found extended translation is set only when the user asked for it using this boot parameter (while when a SEEPROM is found, the boot parameter is ignored). This means that a setup that works under 2.0.36 may fail to boot with 2.2.6 (and require the `linear' keyword for LILO, or the `aic7xxx=extended' kernel boot parameter). --> C > 1024 になるまでは H=64, S=32。 それ以降は 、"extended" 起動パラメータがドライバに与えられているか、 SEEPROM か BIOS の「拡張」ビットが立てられているならば、 H=255, S=63です。 Linux 2.0.36 では、 SEEPROM が見付からない場合はこの拡張変換を常に有効にしますが、 Linux 2.2.6 では、SEEPROM が見付からない場合は拡張変換は、 ユーザがをれを使用するように起動パラメータを指定した時のみ有効になります (SEEPROM が見付かった場合は起動パラメータは無視されます)。 これは、2.0.36 で設定したものが 2.2.6 では起動に失敗するかもしれない (そして、LILO に `linear' キーワードが必要になったり、 カーネルの起動パラメータ `aic7xxx=extended' が必要になったりするかもしれない) ことを意味しています。 <p> <tag/buslogic:/ <p> <!-- H=64, S=32 unless C >= 1024, and moreover extended translation was enabled on the controller, in which case if M < 2^22 then H=128, S=32; otherwise H=255, S=63. However, after making this choice for (C,H,S), the partition table is read, and if for one of the three possibilities (H,S) = (64,32), (128,32), (255,63) the value endH=H-1 is seen somewhere then that pair (H,S) is used, and a boot message is printed "Adopting Geometry from Partition Table". --> C >= 1024 になるまでは H=64, S=32。 それ以降はコントローラの拡張変換が使用されている場合、 M < 2^22 (訳注: 2 GiB) ならば H=128, S=32 で、 さもなければ H=255, S=63 です。 しかし、この (C,H,S) 設定を行った後、パーティションテーブルを読み出します。 そして、可能な 3 つの組み合わせ、(H,S) = (64,32), (128,32), (255,63) のうちから、endH=H-1 になりそうなものを探します。 そして、次のような起動時メッセージを表示します。 "Adopting Geometry from Partition Table" (パーティションテーブルのジオメトリを採用します) <p> <tag/fdomain:/ <p> <!-- Find the geometry information in the BIOS Drive Parameter Table, or read the partition table and use H=endH+1, S=endS for the first partition, provided it is nonempty, or use H=64, S=32 for M < 2^21 (1 GiB), H=128, S=63 for M < 63<tt/*/2^17 (3.9 GiB) and H=255, S=63 otherwise. --> BIOS のドライブパラメータテーブルのジオメトリ情報を探すか、 パーティションテーブルを読んで、 パーティションがあるなら最初のパーティションの(endH+1,endS) を (H,S) として使用します。パーティションがないならば次のようになります: M < 2^21 (1 GiB) ならば H=64, S=32 、 M < 63*2^17 (3.9 GiB) ならば H=128, S=63 、 さもなければ H=255, S=63 。 <p> <tag/in2000:/ <p> <!-- Use the first of (H,S) = (64,32), (64,63), (128,63), (255,63) that will make C <= 1024. In the last case, truncate C at 1023. --> (H,S) = (64,32), (64,63), (128,63), (255,63)のうち、 C <= 1024 となる最初のものを使用します。 最後のものを使うときには、C は 1023 に丸められます。 <p> <tag/seagate:/ <p> <!-- Read C,H,S from the disk. (Horrors!) If C or S is too large, then put S=17, H=2 and double H until C <= 1024. This means that H will be set to 0 if M > 128<tt/*/1024<tt/*/17 (1.1 GiB). This is a bug. --> C,H,S をディスクから読みます(ひぃぃぃぃっ!)。 C か S が大きすぎれば、 S=17, H=2 として、 C <= 1024 となるまで H を倍にしていきます。 これは M > 128*1024*17 (1.1 GiB) のとき、 H が 0 に設定されることを意味します。これはバグです。 <p> <tag/ultrastor and u14_34f:/ <p> <!-- One of three mappings ((H,S) = (16,63), (64,32), (64,63)) is used depending on the controller mapping mode. --> コントローラのマッピングモードに応じて (H,S) = (16,63), (64,32), (64,63) のうちの一つが使用されます。 <p> </descrip> <!-- If the driver does not specify the geometry, we fall back on an educated guess using the partition table, or using the total disk capacity. --> ドライバがジオメトリを指定しなければ、 パーティションテーブルかディスク総容量から経験的に値を求めます。 <p> <!-- Look at the partition table. Since by convention partitions end on a cylinder boundary, we can, given <tt/end = (endC,endH,endS)/ for any partition, just put H = <tt/endH+1/ and S = <tt/endS/. (Recall that sectors are counted from 1.) More precisely, the following is done. If there is a nonempty partition, pick the partition with the largest <tt/beginC/. For that partition, look at <tt/end+1/, computed both by adding <tt/start/ and <tt/length/ and by assuming that this partition ends on a cylinder boundary. If both values agree, or if <tt/endC/ = 1023 and <tt/start+length/ is an integral multiple of <tt/(endH+1)<tt/*/endS/, then assume that this partition really was aligned on a cylinder boundary, and put H = <tt/endH+1/ and S = <tt/endS/. If this fails, either because there are no partitions, or because they have strange sizes, then look only at the disk capacity M. Algorithm: put H = M/(62<tt/*/1024) (rounded up), S = M/(1024<tt/*/H) (rounded up), C = M/(H<tt/*/S) (rounded down). This has the effect of producing a (C,H,S) with C at most 1024 and S at most 62. --> パーティションテーブルを見てみましょう。 パーティションの終わりをシリンダ境界に置くという規則から、 どのようなパーティションであってもパーティションの終わりが <tt/end = (endC,endH,endS)/ であるとき、 単に H = <tt/endH+1/ でS = <tt/endS/ と計算することができます (繰り返しますが、セクタは 1 から数えます)。 もう少し厳密にいうと、以下のようになります。 もしパーティションが存在するならば、 <tt/beginC/ がもっとも大きいパーティションを選びます。 そうして、<tt/end+1/ を、<tt/start/ と <tt/length/ を足す方法と、 パーティションの終わりがシリンダ境界にあると仮定する方法で計算します。 もし両方の答えが一致するか、<tt/endC/ = 1023 かつ <tt/start+length/ が <tt/(endH+1)*endS/ の整数倍ならば、 このパーティションは本当にシリンダ境界にそろえられていると考えられます。 もし、これがだめなようならば、つまりパーティションが全然無いか、 大きさがなんか変ならば、ディスク容量 M のみを見ます。 アルゴリズムは以下のようになり、 この方法は、C を最大 1024, S を最大 62 に押さえるような効果があります: H = M/(62*1024) で切り上げ、 S = M/(1024*H) で切り上げ C = M/(H*S) で切り捨て。 <!-- 2/3 --> <sect> <!-- The Linux IDE 8 GiB limit --> Linux の IDE 8 GiB の壁 <p> <!-- The Linux IDE driver gets the geometry and capacity of a disk (and lots of other stuff) by using an ATA IDENTIFY request. Until recently the driver would not believe the returned value of lba_capacity if it was more than 10% larger than the capacity computed by C<tt/*/H<tt/*/S. However, by industry agreement large IDE disks (with more than 16514064 sectors) return C=16383, H=16, S=63, for a total of 16514064 sectors (7.8 GB) independent of their actual size, but give their actual size in lba_capacity. --> Linux の IDE ドライバは ATA IDENTIFY DEVICE リクエストを使用することにより、 ディスクのジオメトリと容量(とその他多くの情報)を得ます。 最近まで、C*H*S により計算された容量よりも 10% 以上大きい場合は、 ドライバは返された lba_capacity の値を信用しませんでした。 しかし、業界の規定により (16514064 セクタを越える) 大きな IDE ディスクは、 実際のサイズとは無関係の、 計 16514064 セクタ (7.8 GB (訳注: 7.8 GiB または 8.4 GB が正しい)) となる C=16383, H=16, S=63 を返し、実際のサイズは lba_capacity で返します。 <p> <!-- Recent Linux kernels (2.0.34, 2.1.90) know about this and do the right thing. If you have an older Linux kernel and do not want to upgrade, and this kernel only sees 8 GiB of a much larger disk, then try changing the routine <tt/lba_capacity_is_ok/ in <tt>/usr/src/linux/drivers/block/ide.c</tt> into something like --> 最近の Linux カーネル (2.0.34 や 2.1.90) はこのことを知っていて 正しい動作をします。 もし古い Linux カーネルを使っていてアップグレードもしたくなく、 その結果 8 GiB を越える大容量ディスクの 8 GiB しか扱えないようならば、 /usr/src/linux/drivers/block/ide.c 内のルーチン lba_capacity_is_ok を以下のように変更してください。 (訳注: でも特別な理由がない限り、 どうせカーネルの再コンパイルを行うのならば、 素直にアップグレードした方がいいと思います) <tscreen><verb> static int lba_capacity_is_ok (struct hd_driveid *id) { id->cyls = id->lba_capacity / (id->heads * id->sectors); return 1; } </verb></tscreen> <!-- For a more cautious patch, see 2.1.90. --> より良いパッチについては、カーネル 2.1.90 を見てください。 <sect1> <!-- BIOS complications --> BIOS の複雑化 <p> <!-- As just mentioned, large disks return the geometry C=16383, H=16, S=63 independent of the actual size, while the actual size is returned in the value of LBAcapacity. Some BIOSes do not recognize this, and translate this 16383/16/63 into something with fewer cylinders and more heads, for example 1024/255/63 or 1027/255/63. So, the kernel must not only recognize the single geometry 16383/16/63, but also all BIOS-mangled versions of it. Since 2.2.2 this is done correctly (by taking the BIOS idea of H and S, and computing C = capacity/(H*S)). Usually this problem is solved by setting the disk to Normal in the BIOS setup (or, even better, to None, not mentioning it at all to the BIOS). If that is impossible because you have to boot from it or use it also with DOS/Windows, and upgrading to 2.2.2 or later is not an option, use kernel boot parameters. --> 今いったように、大容量ディスクは実際のサイズとは無関係なジオメトリ C=16383, H=16, S=63 を返し、実際のサイズは LBAcapacity の値で返します。 いくつかの BIOS はこれを理解せず、 この 16383/16/63 をより小さいシリンダ数とより大きいヘッド数、 例えば 1024/255/63 や 1027/255/63 といった値に変換します。 そう、カーネルは単一のジオメトリ 16383/16/63 だけではなく、 BIOS によって変換されてしまったジオメトリも見分けなければなりません。 カーネル 2.2.2 からこれは正しく処理されます( BIOS に問い合わせて H と S を得、C = capacity/(H*S) と計算することによって)。 通常この問題は、BIOS 設定でディスクを Normal と設定することで解決します (あるいは、よりよい方法は、None と設定して BIOS に一切認識させない)。 この HDD から起動させなければいけないとか、 DOS/Windows でも使うなどの理由でこれが不可能で、 さらにカーネルを 2.2.2 かそれ以降にアップグレードするという選択も無理ならば、 カーネルの起動パラメータを使ってください。 <p> <!-- If a BIOS reports 16320/16/63, then this is usually done in order to get 1024/255/63 after translation. --> BIOS が 16320/16/63 と報告する場合は、 それは変換後に 1024/255/63 を得る目的で報告されているのです。 <sect1> <!-- Jumpers that select the number of heads --> ヘッド数を決めるためのジャンパ <p> <!-- Many disks have jumpers that allow you to choose between a 15-head an a 16-head geometry. The default settings will give you a 16-head disk. Sometimes both geometries address the same number of sectors, sometimes the 15-head version is smaller. There may be a good reason for this setup: Petri Kaukasoina writes: `A 10.1 Gig IBM Deskstar 16 GP (model IBM-DTTA-351010) was jumpered for 16 heads as default but this old PC (with AMI BIOS) didn't boot and I had to jumper it for 15 heads. hdparm -i tells RawCHS=16383/15/63 and LBAsects=19807200. I use 20960/15/63 to get the full capacity.' For the jumper settings, see <htmlurl name="http://www.storage.ibm.com/techsup/hddtech/hddtech.htm" url="http://www.storage.ibm.com/techsup/hddtech/hddtech.htm">. --> 多くのディスクは 15 ヘッドか 16 ヘッドかのジオメトリを選択可能にする ジャンパを用意しています。 デフォルトの設定は 16 ヘッドのディスクになっているでしょう。 いずれのジオメトリでも同じ総セクタ数の時もあれば、 15 ヘッドの方が総セクタ数が少ない時もあります。 こんなセットアップの際にはよい理由があるかもしれません: Petri Kaukasoina はこういってます: 「10.1 GB の IBM Deskstar 16 GP (model IBM-DTTA-351010) はデフォルトでは 16 ヘッドにジャンパが設定されているが、 この (AMI BIOS の) 古い PC ではブートしないので、 15 ヘッドの方にジャンパを設定する必要があった。 hdparm -i は RawCHS=16383/15/63 で LBAsects=19807200 と報告している。 私はすべての容量を得るために 20960/15/63 で使っている。」 ジャンパの設定については、以下を参照してください。 <htmlurl name="http://www.storage.ibm.com/techsup/hddtech/hddtech.htm" url="http://www.storage.ibm.com/techsup/hddtech/hddtech.htm">. <sect1> <!-- Jumpers that clip total capacity --> 総容量を隠すためのジャンパ <p> <!-- Many disks have jumpers that allow you to make the disk appear smaller than it is. A silly thing to do, and probably no Linux user ever wants to use this, but some BIOSes crash on big disks. The usual solution is to keep the disk entirely out of the BIOS setup. But this may be feasible only if the disk is not your boot disk. --> 多くのディスクはディスクをより小さく見せかけることを可能にする ジャンパを用意しています。 それはばかげたことで、 これを使用したがる Linux ユーザはおそらくいないでしょうが、 大容量ディスクを接続すると一部の BIOS はクラッシュしてしまいます。 通常の解決方法は、ディスクを完全に BIOS に認識させないことです。 しかしこれは起動ディスクではない時しか利用できないでしょう。 <p> <!-- The first serious limit was the 4096 cylinder limit (that is, with 16 heads and 63 sectors/track, 2.11 GB). For example, a Fujitsu MPB3032ATU 3.24 GB disk has default geometry 6704/15/63, but can be jumpered to appear as 4092/16/63, and then reports LBAcapacity 4124736 sectors, so that the operating system cannot guess that it is larger in reality. In such a case (with a BIOS that crashes if it hears how big the disk is in reality, so that the jumper is required) one needs boot parameters to tell Linux about the size of the disk. --> 最初の深刻な制限は 4096シリンダ制限です (これは 16 ヘッドと 63 セクタ毎トラックの場合 2.11GB です)。 例えば、富士通 MPB3032ATU という 3.24 GB のディスクはデフォルトで 6704/15/63 というジオメトリですが、 ジャンパを設定することで 4092/16/63 に見せかけることが可能です。 そして LBAcapacity に対して 4124736 セクタと報告するので、 OS はこのディスクが実際はもっと大容量であると知ることはできません。 (実際にディスクの容量が大きすぎて BIOS がクラッシュするので、 ジャンパが必要になるという)このようなケースでは、 ディスクのサイズについて Linux に教えるために ブートパラメータを指定する必要があります。 <p> <!-- That is unfortunate. Most disks can be jumpered so as to appear as a 2 GB disk and then report a clipped geometry like 4092/16/63 or 4096/16/63, but still report full LBAcapacity. Such disks will work well, and use full capacity under Linux, regardless of jumper settings. --> これはあまりよくない例です。 多くのディスクはジャンパを設定することにより、 2GB のディスクであるかのように見せ、 4092/16/63 や 4096/16/63 といった切り詰めたジオメトリを報告します。 しかし LBAcapacity では完全な値を報告するのです。 このようなディスクは正常に動作しますし、 ジャンパの設定に関わらず Linux の下ではすべての容量を利用できます。 <p> <!-- <label id="jumperbig"> A more recent limit is <ref id="verylarge" name="the 33.8 GB limit">. Linux kernels older than 2.3.21 need a patch to be able to cope with IDE disks larger than this. Some disks larger than this limit can be jumpered to appear as a 33.8 GB disk. For example, the IBM Deskstar 37.5 GB (DPTA-353750) can be jumpered to appear as a 33.8 GB disk, and then reports geometry 16383/16/63 like any big disk, but LBAcapacity 66055248 (corresponding to 65531/16/63, or 4111/255/63)). These, when jumpered for 33.8 GB, again require boot parameters for full capacity under Linux. See also <htmlurl name="the BIOS 33.8 GB limit" url="http://www.storage.ibm.com/techsup/hddtech/bios338gb.htm">. --> <label id="jumperbig"> もっとも最近の制限は <ref id="verylarge" name="33.8 GB の壁"> です。 2.3.21 より古い Linux カーネルでは、 これより容量の大きな IDE ディスクをうまく処理するにはパッチが必要です。 この制限より大きなディスクのいくつかでは 33.8GB ディスクに見せかけるためのジャンパ設定が可能なものがあります。 例えば、IBM Deskstar 37.5 GB disk (DPTA-353750) といったようなこの制限より大きなディスクは、 33.8 GB のディスクに見せかけるためのジャンパ設定が可能で、 (訳注: 2.1 GB に見せかけることのできる) 他の大容量ディスクのように 16383/16/63 というジオメトリを報告しますが、 LBAcapacity は (訳注: 33.8GB に相当する) 66055248 と報告します (65531/16/63 や 4111/255/63 に相当します)。 33.8GB に見せかけるためのジャンパ設定をしたこれらのディスクもまた、 Linux の下ですべての容量を利用するためにブートパラメータを必要とします。 <htmlurl name="the BIOS 33.8 GB limit" url="http://www.storage.ibm.com/techsup/hddtech/bios338gb.htm"> も参照してください。 <sect> <!-- The Linux 65535 cylinder limit --> Linux の 65535 シリンダの壁 <p> <!-- The <tt/HDIO_GETGEO/ ioctl returns the number of cylinders in a short. This means that if you have more than 65535 cylinders, the number is truncated, and (for a typical SCSI setup with 1 MiB cylinders) a 80 GiB disk may appear as a 16 GiB one. Once one recognizes what the problem is, it is easily avoided. --> <tt/HDIO_GETGEO/ ioctl は short (訳注: short int つまり 16ビット) でシリンダ数を返します。 これは、65535 シリンダより多い場合には数字が切り捨てられて、 例えば(典型的な SCSI の設定では 1 シリンダ 1 MiB なので) 80 GiB のディスクは 16 GiB に見えるかもしれないことを意味します。 いったん何が問題なのか分かってしまえば、それを回避することは簡単です。 <sect1> <!-- IDE problems with 34+ GB disks --> 34 GB 超のディスクにおける IDE の問題 <label id="verylarge"> <p> <!-- Drives larger than 33.8 GB will not work with kernels older than 2.3.21. The details are as follows. Suppose you bought a new IBM-DPTA-373420 disk with a capacity of 66835440 sectors (34.2 GB). Pre-2.3.21 kernels will tell you that the size is 769*16*63 = 775152 sectors (0.4 GB), which is a bit disappointing. And giving command line parameters hdc=4160,255,63 doesn't help at all - these are just ignored. What happens? The routine idedisk_setup() retrieves the geometry reported by the disk (which is 16383/16/63) and overwrites what the user specified on the command line, so that the user data is used only for the BIOS geometry. The routine current_capacity() or idedisk_capacity() recomputes the cylinder number as 66835440/(16*63)=66305, but since this is stored in a short, it becomes 769. Since lba_capacity_is_ok() destroyed id->cyls, every following call to it will return false, so that the disk capacity becomes 769*16*63. For several kernels a patch is available. A patch for 2.0.38 can be found at <htmlurl url="ftp://ftp.us.kernel.org/pub/linux/kernel/people/aeb/" name="ftp.kernel.org">. A patch for 2.2.12 can be found at <htmlurl name="www.uwsg.indiana.edu" url="http://www.uwsg.indiana.edu/hypermail/linux/kernel/9910.2/0636.html">. The 2.2.14pre kernels do support these disks. In the 2.3.* kernel series, there is support for these disks since 2.3.21. One can also `solve' the problem in hardware by <ref id="jumperbig" name="using a jumper"> to clip the size to 33.8 GB. In many cases a <ref id="biosupgrades" name="BIOS upgrade"> will be required if one wants to boot from the disk. --> 33.8 GB より大容量なドライブは、2.3.21 より古いカーネルではうまく動作しません。 (訳注: この章の最後の方にも書いてありますが、2.2.14 以降でもサポートしています。) その詳細は以下の通りです。 ある日あなたが新たに 66835440 セクタ (34.2 GB) の IBM-DPTA-373420 ディスクを買ってきたとしましょう。 2.3.21 以前のカーネルは、それのサイズを 769*16*63 = 775152 セクタ (0.4 GB) と報告し、ちょっとがっかりするでしょう。 そしてコマンドラインパラメータ hdc=4160,255,63 を与えても、 事態はまったく解決しないのです - これは無視されます。 一体何が起きているのでしょう? ルーチン idedisk_setup() では、 ディスクが報告するジオメトリ(16383/16/63 です)を受け取り、 ユーザがコマンドラインで指定した値で上書きします。 この値は BIOS ジオメトリのためだけに使用されるものです。 ルーチン current_capacity() や idedisk_capacity() は、 66835440/(16*63)=66305 という感じでシリンダ数を再計算しますが、 この値は short で格納されるので、 769 になってしまいます。 lba_capacity_is_ok() は id->cyls を破壊するので、 その後の呼び出しすべてに対して嘘の値を返し、 その結果ディスクの容量は 769*16*63 になります。 いくつかのカーネルに対してはパッチが提供されています。 2.0.38 用のパッチは <htmlurl url="ftp://ftp.us.kernel.org/pub/linux/kernel/people/aeb/" name="ftp.kernel.org"> に用意されています。 2.2.12 用のパッチは <htmlurl name="www.uwsg.indiana.edu" url="http://www.uwsg.indiana.edu/hypermail/linux/kernel/9910.2/0636.html">. に用意されています。 2.2.14pre カーネルはこれらのディスクをサポートしています。 2.3.* カーネルシリーズでは、2.3.21 からこれらのディスクをサポートしています。 また、ディスクのサイズを 33.8GB に切り詰めるために、ハードウェア的に <ref id="jumperbig" name="ジャンパを設定する"> ことでも問題を「解決」することができます。 ハードディスクからブートしようとするのならば、 多くの場合 <ref id="biosupgrades" name="BIOS アップグレード"> が必要になるでしょう。 <sect> <!-- Extended and logical partitions --> 拡張パーティションと論理パーティション <p> <!-- <ref id="partitiontable" name="Above,"> we saw the structure of the MBR (sector 0): boot loader code followed by 4 partition table entries of 16 bytes each, followed by an AA55 signature. Partition table entries of type 5 or F or 85 (hex) have a special significance: they describe <it>extended</it> partitions: blobs of space that are further partitioned into <it>logical</it> partitions. (So, an extended partition is only a box, it cannot be used itself, one uses the logical partitions inside.) Only the location of the first sector of an extended partition is important. This first sector contains a partition table with four entries: one a logical partition, one an extended partition, and two unused. In this way one gets a chain of partition table sectors, scattered over the disk, where the first one describes three primary partitions and the extended partition, and each following partition table sector describes one logical partition and the location of the next partition table sector. --> <ref id="partitiontable" name="前述の通り、"> 我々は MBR (セクタ 0) の構造を知っています: シグネチャ AA55、 続けて 16 バイトずつの 4 つのパーティションテーブルのエントリ、 続けてブートローダのコード。 タイプが(16進数で) 5 か F か 85 のパーティションテーブルエントリ (訳注: 5, F, 85 は順に拡張パーティション、Windows95 拡張パーティション、 Linux 拡張パーティション)は特別な意味があります。これらは、 その内部をさらに<it>論理</it>パーティションとして分割される空間である、 <it>拡張</it>パーティションであることを意味しています。 (そう、拡張パーティションとは単なる箱で、それ自身を使用することはできず、 その中の論理パーティションを使うことになります。) 拡張パーティションの一番目のセクタの位置のみが重要です。 この一番目のセクタは、四つのパーティションテーブルを含んでいます: 一つは論理パーティション、一つは拡張パーティション、そして二つは未使用です。 このようにして、ディスク全体に散らばったパーティションテーブルセクタの 連鎖構造ができあがります。 最初のセクタは 3 つの基本パーティションとひとつの拡張パーティションを 規定します。 これに続くパーティションテーブルセクタはそれぞれ、 ひとつの論理パーティションと次のパーティションテーブルセクタの 位置を規定します。 <p> <!-- It is important to understand this: When people do something stupid while partitioning a disk, they want to know: Is my data still there? And the answer is usually: Yes. But if logical partitions were created then the partition table sectors describing them are written at the beginning of these logical partitions, and data that was there before is lost. --> これは次のことを理解するために重要です: ディスクのパーティションを切る際に間抜けなことをした時 (訳注: パーテイションを削除してしまった時など)、 人々は「私のデータはまだそこにあるの?」ということを知りたがります。 そしてその答は決まってこうです。 「はい、まだあります。しかし論理パーティションを作成したら、 それを記述するパーティションテーブルセクタは これらの論理パーティションの先頭に書き込まれるので、 以前そこにあったデータは失われますよ。」 <p> <!-- The program sfdisk will show the full chain. E.g., --> プログラム sfdisk は完全なチェーンを表示できます。例えば、 <tscreen><verb> # 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 # </verb></tscreen> <p> <!-- It is possible to construct bad partition tables. Many kernels get into a loop if some extended partition points back to itself or to an earlier partition in the chain. It is possible to have two extended partitions in one of these partition table sectors so that the partition table chain forks. (This can happen for example with an fdisk that does not recognize each of 5, F, 85 as an extended partition, and creates a 5 next to an F.) No standard fdisk type program can handle such situations, and some handwork is required to repair them. The Linux kernel will accept a fork at the outermost level. That is, you can have two chains of logical partitions. Sometimes this is useful - for example, one can use type 5 and be seen by DOS, and the other type 85, invisible for DOS, so that DOS FDISK will not crash because of logical partitions past cylinder 1024. --> おかしなパーティションテーブルを構築することも可能です。 拡張パーティションのチェーンが自分自身を指すか、 あるいはもっと前のパーティションを指す場合、多くのカーネルはループに陥ります。 1つのパーティションテーブル内に 2つの拡張パーティションを持つことも可能です。 これはパーティションテーブルのチェーンが分岐することを意味します。 (これは例えば、5, F, 85 のそれぞれを拡張パーティションとして認識できない fdisk で、F の次に 5 を作る、という方法で可能になります) <!-- 一般的でない fdisk タイプのプログラムはそのような状況を取り扱うことができ、 それらを修復する必要のある手作業で使われます。 --> 普通の fdisk タイプのプログラムではそのような状況を取り扱うことができないので、 それを修復するためには手作業が必要となります。 Linux カーネルは、一番外側のレベルにおいて分岐を受け付けます。 これは、2つの論理パーティションのチェーンを持つことができることを意味します。 時々、これは便利です - 例えば、 一方ではタイプ 5 を使用して DOS から参照できるようにし、 もう片方ではタイプ 85 を使用して DOS から見えないようにします。 つまり、DOS の fdisk が、1024 シリンダを越える論理パーティションによって クラッシュしないようにできるのです。 <p> <sect> <!-- Problem solving --> 問題の解決 <p> <!-- Many people think they have problems, while in fact nothing is wrong. Or, they think that the problems they have are due to disk geometry, while in fact disk geometry has nothing to do with the matter. All of the above may have sounded complicated, but disk geometry handling is extremely easy: do nothing at all, and all is fine; or perhaps give LILO the keyword `linear' if it doesn't get past `LI' when booting. Watch the kernel boot messages, and remember: the more you fiddle with geometries (specifying heads and cylinders to LILO and fdisk and on the kernel command line) the less likely it is that things will work. Roughly speaking, all is fine by default. --> 問題を抱えたと思う人の多くは、しかし実際には何も悪い点はありません。 また、抱えている問題の原因がディスクのジオメトリにあると思われる場合でも、 実際にはディスクのジオメトリには何の問題もありません。 上で述べたようなすべてのことが事態を複雑にしていますが、 ディスクのジオメトリの扱いは非常に簡単です: まったく申し分なければ何もする必要はありません; もし起動時に `LI' の先に進まない場合は LILO にキーワード `linear' を与えてください。 カーネルの起動メッセージを見て思い出してください: (LILO や fdisk やカーネルコマンドラインでヘッド数やシリンダ数を 与えて)ジオメトリをいじくればいじくるほど、 正常には動作しなくなるでしょう。おおざっぱにいえば、デフォルトが一番なのです。 <p> <!-- And remember: nowhere in Linux is disk geometry used, so no problem you have while running Linux can be caused by disk geometry. Indeed, disk geometry is used only by LILO and by fdisk. So, if LILO fails to boot the kernel, that may be a geometry problem. If different operating systems do not understand the partition table, that may be a geometry problem. Nothing else. In particular, if mount doesnt seem to work, never worry about disk geometry - the problem is elsewhere. --> さらに思い出してください: Linux がディスクのジオメトリを使わない所、 つまりLinux が動作している間は、 ディスクのジオメトリによって問題が引き起こされることはありません。 それどころか、ディスクのジオメトリは LILO と fdisk だけに使用されます。 そう、LILO がカーネルの起動に失敗する場合は、 ジオメトリに問題があるかもしれません。 異なる OS がパーティションテーブルを理解しない場合は、 ジオメトリに問題があるかもしれません。でもそれだけです。 とりわけ、mount が動作しないように思える場合でも、 ディスクのジオメトリには何の関係もありません - 問題は他の所にあります。 <p> <sect1> <!-- Problem: My IDE disk gets a bad geometry when I boot from SCSI. --> 問題: SCSI から起動した時、IDE ディスクが変なジオメトリを持っている <p> <!-- It is quite possible that a disk gets the wrong geometry. The Linux kernel asks the BIOS about hd0 and hd1 (the BIOS drives numbered 80H and 81H) and assumes that this data is for hda and hdb. But on a system that boots from SCSI, the first two disks may well be SCSI disks, and thus it may happen that the fifth disk, which is the first IDE disk hda, gets assigned a geometry belonging to sda. Such things are easily solved by giving boot parameters `hda=C,H,S' for the appropriate numbers C, H and S, either at boot time or in /etc/lilo.conf. --> ディスクが変なジオメトリを持つのはとてもありがちです。 Linux カーネルは hd0 と hd1 (80H と 81H の数字がふられた BIOS ドライブ) について BIOS に問い合わせ、 このデータが hda と hdb のものだと仮定します。 しかし SCSI から起動したシステム上では、 最初の二つのディスクが SCSI ディスクでしょうから、 最初の IDE ディスク hda である 5番目のディスクに対して sda のジオメトリが割り当てられるなんてことが起きるかもしれません。 これは、起動時や /etc/lilo.conf において、適切な数字 C, H, S を使って ブートパラメータ `hda=C,H,S' を与えることで簡単に解決できます。 <p> <sect1> <!-- Nonproblem: Identical disks have different geometry? --> 問題なし: 同じディスクが異なるジオメトリを持っている? <p> <!-- `I have two identical 10 GB IBM disks. However, fdisk gives different sizes for them. Look: --> 「私はまったく同じ IBM 製のディスクを 2台持っています。 しかし、fdisk が表示するサイズは異なっています。こんな感じ: <tscreen><verb> # 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 </verb></tscreen> <!-- How come?' --> 何ででしょ?」 <!-- What is happening here? Well, first of all these drives really are 10gig: hdb has size 255<tt/*/63<tt/*/1232<tt/*/512 = 10133544960, and hdd has size 16<tt/*/63<tt/*/19650<tt/*/512 = 10141286400, so, nothing is wrong and the kernel sees both as 10.1 GB. Why the difference in size? That is because the kernel gets data for the first two IDE disks from the BIOS, and the BIOS has remapped hdb to have 255 heads (and 16<tt/*/19650/255=1232 cylinders). The rounding down here costs almost 8 MB. --> 何が起きているのでしょう? そう、まず第一に、これらのドライブはしっかり 10 ギガバイト使えています: hdb は 255*63*1232*512 = 10133544960 バイトで、 hdd は 16*63*19650*512 = 10141286400 バイトですが、 何も悪い所はないしカーネルはどちらも 10.1 GB であると理解しています。 では何故サイズが違うのでしょう? それは、カーネルは最初の二台の IDE ディスクについては BIOS から情報を得、 その BIOS は hdb を 255 ヘッドで再マップしているからです (16*19650/255=1232 シリンダ)。 この丸めによる損失は 8MB 弱です。 <p> <!-- If you would like to remap hdd in the same way, give the kernel boot parameters `hdd=1232,255,63'. --> hdd も同じ方法で再マップしたいのならば、 カーネルのブートパラメータに `hdd=1232,255,63' を与えてください。 <sect1> <!-- Nonproblem: fdisk sees much more room than df? --> 問題なし: df より fdisk の方がパーティションが大きく見える <label id="df_fdisk"> <p> <!-- fdisk will tell you how many blocks there are on the disk. If you make a filesystem on the disk, say with mke2fs, then this filesystem needs some space for bookkeeping - typically something like 4% of the filesystem size, more if you ask for a lot of inodes during mke2fs. For example: --> fdisk はブロックがディスク上にいくつ存在するかを報告します。 mke2fs を使ってディスク上にファイルシステムを作った場合、 ファイルシステムは簿記(bookkeeping)のためのいくらかのスペースを必要とします - 通常はファイルシステムのサイズの 4% くらいで、 mke2fs する際に多くの inode を作るとより増えます。 以下は例です: <tscreen><verb> # 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 /somewhere # df /somewhere Filesystem 1024-blocks Used Available Capacity Mounted on /dev/hda9 3574475 13 3369664 0% /mnt # df -i /somewhere Filesystem Inodes IUsed IFree %IUsed Mounted on /dev/hda9 4096000 11 4095989 0% /mnt # </verb></tscreen> <!-- We have a partition with 4095976 blocks, make an ext2 filesystem on it, mount it somewhere and find that it only has 3574475 blocks - 521501 blocks (12%) was lost to inodes and other bookkeeping. Note that the difference between the total 3574475 and the 3369664 available to the user are the 13 blocks in use plus the 204798 blocks reserved for root. This latter number can be changed by tune2fs. This `-i 1024' is only reasonable for news spools and the like, with lots and lots of small files. The default would be: --> まず、4095976 ブロックのパーティションがあります。 ここに ext2 ファイルシステムを作成し、適当な所にマウントします。 すると 3574475 ブロックになってしまいます - 521501 ブロック (12%) は inode と他の簿記用スペースに消費されたのです。 合計 3574475 と 3369664 の間の差は、ユーザが 13 ブロックを使用していて、 さらに 204798 ブロックが root のために予約されているためであることに 注意してください。 後者は tune2fs で変更できます。 この `-i 1024' はニューススプールなどの小さいファイルが山ほどある 場合にのみ適しています。 デフォルトではこうなります: <tscreen><verb> # mke2fs /dev/hda9 # mount /dev/hda9 /somewhere # df /somewhere Filesystem 1024-blocks Used Available Capacity Mounted on /dev/hda9 3958475 13 3753664 0% /mnt # df -i /somewhere Filesystem Inodes IUsed IFree %IUsed Mounted on /dev/hda9 1024000 11 1023989 0% /mnt # </verb></tscreen> <!-- Now only 137501 blocks (3.3%) are used for inodes, so that we have 384 MB more than before. (Apparently, each inode takes 128 bytes.) On the other hand, this filesystem can have at most 1024000 files (more than enough), against 4096000 (too much) earlier. --> 今度は 137501 ブロック(3.3%)のみが inode のために使用され、 その結果以前より 384 MB も増えてます。 (inode 1つにつき 128 バイト使ってるみたいです。) 一方、先の場合では 4096000 ファイル保存できるのに対し(どう見ても多すぎ)、 このファイルシステムでは最大 1024000 ファイルが保存できます (これでも十分すぎます)。 <sect> 日本語版について <p> 翻訳に関するご意見は JF プロジェクト <JF@linux.or.jp> 宛に連絡してください。 v2.2j の翻訳にあたっては、堀江誠一さん <tt/shorie@ibm.net/ による Large Disk mini HOWTO v1.0 の翻訳から 多くの部分を流用させていただきました。深く感謝します。 </article>