Linux Partition HOWTO <author>Kristan Koehntopp, kris@koehntopp.de <date>$Id: Partition.sgml,v 2.4 1997/11/03 06:27:22 kris Exp $ <trans>田野島 秀俊, tano@sainet.or.jp (1997/11/25) <!-- $Log: Partition.sgml,v $ Revision 1.4 2002/02/16 11:34:49 mdk Partition.sgml: <bf>archived notice</bf> Revision 1.3 2002/02/08 11:23:35 mdk * docs/Partition/Makefile (SGML2HTML): added. * docs/Partition/info (ITEM): diskmanage -> archived. * docs/Partition/Partition.sgml: add archived notice. Revision 1.2 2000/05/12 15:21:03 nakano LINUXDOCTR_2000_05_09 branch merge: migration to linuxdoctr DTD for translation docs Revision 1.1.1.1.2.1 2000/05/09 12:57:00 nakano linuxdoc->linuxdoctr Revision 1.1.1.1 1999/02/22 19:20:43 baba Revision 2.4 1997/11/03 06:27:22 kris Minor changes due to reader queries. Revision 2.3 97/07/26 21:47:15 kris Spelling changes. Thanks to dirk@roxel.ms.sub.org (Dirk Nimmich). Revision 2.2 97/07/15 20:07:21 kris Released to HOWTO maintainer. Revision 2.1 97/07/15 19:49:37 kris First useable SGML version - Markup finished. - Repartitioned into smaller sections and new section headers. Revision 2.0 97/07/15 19:12:44 kris Initial transformation to linuxdoc SGML Revision 1.4 97/07/14 10:12:01 kris Revised and edited for third public release. - More spelling corrections. - Additional information about device numbers. Revision 1.3 97/01/24 13:08:02 kris Some minor spelling corrections. Revision 1.2 96/11/29 13:42:04 kris Revised and edited for second public release. Added: - Introduction - Introductory chapter on partitions. - Example Modified: - Turned File Systems and Fragmentation into an extra chapter. Revision 1.1 96/11/29 10:54:06 kris Initial revision --> <abstract> <!-- This Linux Mini-HOWTO teaches you how to plan and layout disk space for your Linux system. It talks about disk hardware, partitions, swap space sizing and positioning considerations. file systems, file system types and related topics. The intent is to teach some background knowledge, not procedures. --> この Linux Mini-HOWTO では Linux システムのディスク領域を計画しレイア ウトする方法について解説します。ディスクのハードウエア面やパーティショ ン、スワップ領域のサイズとそれの配置の際考慮すること、ファイルシステム、 ファイルシステム型、及び関連するトピックについて述べています。この文書 の意図は背景的知識を伝授することで手順を教えることではありません。 </abstract> <p> <bf>注意: この文書はかなり以前に書かれたものなので、 いまどきの Linux 環境にはあてはまらない箇所があります。 (JF Project)</bf> </p> <toc> <sect>はじめに <sect1>この文書は？ <p> <!-- This is a Linux Mini-HOWTO text. A Mini-HOWTO is a small text explaining some business related to Linux installation and maintenance tutorial style. It's mini, because either the text or the topic it discusses are too small for a real HOWTO or even a book. A HOWTO is not a reference: that's what manual pages are for. --> これは Linux Mini-HOWTO 文書です。Mini-HOWTO は Linux のインストールや 維持に関する事を説明した短い文書です。 mini の付かない HOWTO や本にさ えなるような文書に比べて、量が少なかったり議論する話題の範囲が狭かった りするので mini なのです。HOWTO はリファレンスではありません。それはマ ニュアルページの役目です。 <sect1>この文書にはなにが書いてありますか？また関連文書は？ <p> <!-- This particular Mini-HOWTO teaches you how to plan and layout disk space for your Linux system. It talks about disk hardware, partitions, swap space sizing and positioning considerations, file systems, file system types and related topics. The intent is to teach some background knowlegde, so we are talking mainly principles and not tools in this text. --> この Mini-HOWTO は Linux システムのディスク領域を計画立ててレイアウト する方法についての文書です。ディスクのハードウエア面やパーティション、 スワップ領域のサイズとそれの配置の際考慮すること、ファイルシステム、ファ イルシステム型、及び関連するトピックについて述べています。この文書の意 図は背景的知識を伝授することで、それゆえツール類の紹介ではなく、主に原 理について述べます。 <!-- Ideally, this document should be read before your first installation, but this is somehow difficult for most people. First timers have other problems than disk layout optimization, too. So you are probably someone who just finished a Linux installation and is now thinking about ways to optimize this installation or how to avoid some nasty miscalculations in the next one. Well, expect some desire to tear down and rebuild your installation when you are finished with this text. :-) --> 理想的には、この文書は初めてのインストールの前に読まれるべきですが、ほ とんどの人にはちょっと難しいでしょう。初心者はディスクレイアウトの最適 化よりも重大な他の問題も抱えています。従ってこれを読んでいるあなたはひょっ とすると、ちょうど Linux のインストールを終ったところで、このインストー ルしたシステムの最適化の方法か、次のインストールでのやっかいな計算違い の避け方を今考えているのかもしれません。うーん、ではこの文書を読み終え たら、インストールを白紙に戻して再構築したくなるような欲求が生じるよう に期待しましょう。:-) <!-- This Mini-HOWTO limits itself to planning and layouting disk space most of the time. It does not discuss the usage of fdisk, LILO, mke2fs or backup programs. There are other HOWTOs that address these problems. Please see the Linux HOWTO Index for current information on Linux HOWTOs. There are instructions for obtaining HOWTO documents in the index, too. --> この Mini-HOWTO はディスク領域の計画とレイアウトのやり方にほとんどの行 数を割いています。つまり fdisk, LILO, mke2fs やバックアッププログラム の使い方については述べていません。これらの問題については他の HOWTO があ ります。Linux HOWTO の最新情報は Linux HOWTO Index を見てください。こ の中に HOWTO 文書を入手するための説明もあります。 <!-- To learn how to estimate the various size and speed requirements for different parts of the filesystem, see "Linux Multiple Disks Layout mini-HOWTO", by Gjoen Stein <gjoen@nyx.net>. --> ファイルシステムの異なった部品に、どんなサイズやスピードが必要かを見積 もる方法を学ぶために、"Linux Multiple Disks Layout mini-HOWTO", by Gjoen Stein <gjoen@nyx.net>著 を見て下さい (訳注:現在は Disk-HOWTO になってます。) <!-- For instructions and considerations regarding disks with more than 1024 cylinders, see "Linux Large Disk mini-HOWTO", Andries Brouwer <aeb@cwi.nl>. --> 1024シリンダ以上のディスクに関する解説と考察については、 "Linux Large Disk mini-HOWTO", Andries Brouwer <aeb@cwi.nl> 著 を見て下さい。 <!-- For instructions on limiting disk space usage per user (quotas), see "Linux Quota mini-HOWTO", by Albert M.C. Tam <bertie@scn.org> --> ユーザーごとに使用するディスク領域を制限する方法(quotas)の解説について は、"Linux Quota mini-HOWTO", by Albert M.C. Tam <bertie@scn.org> <!-- Currently, there is no general document on disk backup, but there are several documents with pointers to specific backup solutions. See "Linux ADSM Backup mini-HOWTO", by Thomas Koenig <Thomas.Koenig@ciw.uni-karlsruhe.de> for instructions on integrating Linux into an IBM ADSM backup environment. See "Linux Backup with MSDOS mini-HOWTO", by Christopher Neufeld <neufeld@physics.utoronto.ca> for information about MS-DOS driven Linux backups. --> 現在、ディスクバックアップについての一般的な文書はありません。しかし特 定のバックアップ方法を示した文書がいくつかあります。Linux を IBM ADSMバックアップ環境に統合する方法の解説については"Linux ADSM Backup mini-HOWTO", Thomas Koenig <Thomas.Koenig@ciw.uni-karlsruhe.de>著を見 てください。Linux で MS-DOS のバックアップをとるための情報は"Linux Backup with MSDOS mini-HOWTO", Christopher Neufeld <neufeld@physics.utoronto.ca>著を見てください。 <!-- For instructions on writing and submitting a HOWTO document, see the Linux HOWTO Index, by Greg Hankins <gregh@sunsite.unc.edu>. --> HOWTO文書を書いたり提出するための解説については the Linux HOWTO Index, Greg Hankins <gregh@sunsite.unc.edu>著を見てください。 <!-- Browsing through /usr/src/linux/Documentation can be very instructive, too. See ide.txt and scsi.txt for some background information on the properties of your disk drivers and have a look at the filesystems/ subdirectory. --> /usr/src/linux/Documentation 以下の文書に目を通すのも大変ためになりま す。ディスクドライバの特性に関する背景的知識を得るためには ide.txt と scsi.txt を見てください。また、filesystems/ サブディレクトリ以下のファ イルにも目を通してください。 <sect>ともあれパーティションとは？ <p> <!-- When PC hard disks were invented people soon wanted to install multiple operating systems, even if their system had only one disk. So a mechanism was needed to divide a single physical disk into multiple logical disks. So that's what a partition is: A contiguous section of blocks on your hard disk that is treated like a completely seperate disk by most operating systems. --> PC のハードディスクが発明された時、人々はすぐに複数のオペレーティング システムをインストールしたくなりました。システムには唯1つのディスクし かない場合にさえ、です。それで1つの物理的ディスクに複数の論理的ディス クを割り当てる機構が必要になりました。パーティションとは、ほとんどのオ ペレーティングシステムで完全に別々のディスクとして扱われる、ハードディ スク上の連続したブロック領域のことです。 <!-- It is fairly clear that partitions must not overlap: An operating system will certainly not be pleased, if another operating system installed on the same machine were overwriting important information because of overlapping partitions. There should be no gap between adjacent partitions, too. While this constellation is not harmful, you are wasting precious disk space by leaving space between partitions. --> パーティションが重なってはいけないのはすぐに分かるでしょう。パーティショ ンが重なっていて、あるオペレーティングシステムが同じマシンにインストー ルされた別のオペレーティングシステムの重要な情報に上書きしていたら、嬉 しいことにならないのは明らかです。また隣接したパーティションの間にはす き間がないほうがよいです。あっても有害ではありませんが、パーティション 間にスペースを残すことで貴重なディスクスペースを無駄にしてしまいます。 <!-- A disk need not be partitioned completely. You may decide to leave some space at the end of your disk that is not assigned to any of your installed operating systems, yet. Later, when it is clear which installation is used by you most of the time, you can partition this left over space and put a file system on it. --> ディスクを完全に仕切る必要はありません。インストール済みのどのオペレー ティングシステムにも割り当てていないスペースをディスクの最後に置いてお いて差し支えありません。あとでインストールしたどのシステムを最もよく使 うかが明らかになったとき、この残ったスペースを仕切り、そこにファイルシ ステムを置くことができます。 <!-- Partitions can not be moved nor can they be resized without destroying the file system contained in it. So repartitioning usually involves backup and restore of all file systems touched during the repartitioning. In fact it is fairly common to mess up things completely during repartitioning, so you should back up anything on any disk on that particular machine before even touching things like <tt/fdisk/. --> パーティションは動かせませんし、その中のファイルシステムを破壊せずにサ イズを変更することもできません。ですから通常、パーティションのやり直し にはそれが及ぶすべてのファイルシステムのバックアップとリストアが必要に なります。実際のところ、パーティションのやり直しで物事が完全にめちゃめ ちゃになるのはよくあることです。そこで <tt/fdisk/ の様なパーティション を扱うコマンドを使う際は、対象マシンの全てのディスクのすべてをバックアッ プするべきです。 <!-- Well, some partitions with certain file system types on them actually <em/can/ be split into two without losing any data (if you are lucky). For example there is a program called "fips" for splitting MS-DOS partitions into two to make room for a Linux installation without having to reinstall MS-DOS. You are still not going to touch these things without carefully backing up everything on that machine, aren't you? --> 実際には、ファイルシステムのタイプによってはデータを失わずにパーティショ ンを2つにわけることが<em/できます/。(幸運ならば。) 例えば、"fips"と呼 ばれるプログラムは、MS-DOS のインストールをやり直すことなく Linux のイ ンストール領域を作るために、MS-DOS パーティションを2つに分けます。で も、マシンの全てを慎重にバックアップする前に、これらのモノに手を出すべ きではありません。でしょ？ <sect1>バックアップは重要 <p> <!-- Tapes are your friend for backups. They are fast, reliable and easy to use, so you can make backups often, preferably automatically and without hassle. --> テープはバックアップの友です。高速で信頼でき、使い易く、それゆえ頻繁に、 （可能なら）自動的に、気負うことなくバックアップできます。 <!-- Step on soapbox: And I am talking about real tapes, not that disk controller driven ftape crap. Consider buying SCSI: Linux does support SCSI natively. You don't need to load ASPI drivers, you are not losing precious HMA under Linux and once the SCSI host adapter is installed, you just attach additional disks, tapes and CD-ROMs to it. No more I/O addresses, IRQ juggling or Master/Slave and PIO-level matching. --> 声を大にして言いましょう：私は真のテープドライブについて話しているので あって ftape なんてものについて言っているのではありません。SCSI を買う ことにしましょう：Linux は SCSI をネイティブにサポートしています。ASPI ドライバは必要ないし、Linux では貴重な HMA も失わずに住みます。既に SCSI ホストアダプタがインストールされていれば増設ディスク、テープ、 CD-ROM を取り付けるだけです。もはや I/O アドレス、IRQ の衝突回避、マス ター／スレーブ、PIO-level matching などに悩まされなくて済みます。 <!-- Plus: Proper SCSI host adapters give you high I/O performance without much CPU load. Even under heavy disk activity you will experience good response times. If you are planning to use a Linux system as a major USENET news feed or if you are about to enter the ISP business, don't even think about deploying a system without SCSI. Climb of soapbox. --> 加えて：まともな SCSI ホストアダプタは CPU の多大な負荷なしで高い I/O パフォーマンスを得ることができます。ハードなディスク負荷のもとでも良い 応答時間を体感できます。Linux システムを主要な USENET ニュースの配布用 として使う予定だったり、ISP(インターネットサービスプロバイダ)ビジネス にとびこもうとするつもりなら、SCSI なしでシステムを設計、構築しような んて夢にも思わないことです。いいですか？ <sect1>デバイス番号とデバイス名 <p> <!-- The number of partitions on an Intel based system was limited from the very beginning: The original partition table was installed as part of the boot sector and held space for only four partition entries. These partitions are now called primary partitions. When it became clear that people needed more partitions on their systems, logical partitions were invented. The number of logical partitions is not limited: Each logical partition contains a pointer to the next logical partition, so you can have a potentially unlimited chain of partition entries. --> インテルベースのシステムでのパーティションの数は黎明期から制限されてい ました。オリジナルのパーティションテーブルはブートセクタの一部としてイ ンストールされ、たった4つのパーティションエントリ分の領域しかありませ んでした。このパーティションは現在では基本(primary)パーティションと呼 ばれています。人々が自分のシステムにもっと多くのパーティションを必要と することが明らかになると、論理(logical)パーティションが考え出されまし た。論理パーティションの数は無制限です：それぞれの論理パーティションは 次の論理パーティションへのポインタを持っています。そのため論理的にはパー ティションエントリの無限のつながりを持つことができます。 <!-- For compatibility reasons, the space occupied by all logical partitions had to be accounted for. If you are using logical partitions, one primary partition entry is marked as "extended partition" and its starting and ending block mark the area occupied by your logical partitions. This implies that the space assigned to all logical partitions has to be contiguous. There can be only one extended partition: no <tt/fdisk/ program will create more than one extended partition. --> 互換性を確保するために、全論理パーティションが占める領域は明確に示され ている必要があります。論理パーティションを使うときは1つの基本パーティ ションエントリが「拡張(extended)パーティション」として指定され、その最 初と最後のブロックの中に、すべての論理パーティションが収まっている必要 があります。これは、全論理パーティションに割り当てられた領域が連続して いる必要があるということを暗に示しています。 拡張パーティションは一つ しか置けません。 <tt/fdisk/ プログラムで複数の拡張パーティションをつく ることはできません。 <!-- Linux cannot handle more than a limited number of partitions per drive. So in Linux you have 4 primary partitions (3 of them useable, if you are using logical partitions) and at most 15 partitions altogether on an SCSI disk (63 altogether on an IDE disk). --> Linux では、ドライブ一台に対して扱うことのできるパーティションの数に制 限があります。 Linux で使える基本パーティションは4つまで(論理パーティ ションを使うのなら3つまで)、SCSI ディスクでは基本、論理あわせて最大1 5のパーティションを使えます(IDE ディスクではあわせて63)。 <!-- In Linux, partitions are represented by device files. A device file is a file with type c (for "character" devices, devices that do not use the buffer cache) or b (for "block" devices, which go through the buffer cache). In Linux, all disks are represented as block devices only. Unlike other Unices, Linux does not offer "raw" character versions of disks and their partitions. --> Linux では、パーティションはデバイスファイルで表されます。デバイスファ イルとは c タイプ(「キャラクタデバイス」: バッファキャッシュを使わない デバイス)か、b タイプ(「ブロックデバイス」: バッファキャッシュを利用す るデバイス)のファイルの事です。Linux では全てのディスクがブロックデバ イスとしてのみ扱われます。他の Unics達とは異なり、Linux ではディスクや そのパーティションに"raw"キャラクタバージョンはありません。 <!-- The only important thing with a device file are its major and minor device number, shown instead of the files size: --> デバイスファイル関係で唯一つ重要なことはそれがメジャー/マイナー デバイ ス番号を持つことで、それらはファイルサイズの代わりに表示されます: <tscreen><code> $ ls -l /dev/hda brw-rw---- 1 root disk 3, 0 Jul 18 1994 /dev/hda ^ ^ | マイナーデバイス番号 メジャーデバイス番号 </code></tscreen> <!-- When accessing a device file, the major number selects which device driver is being called to perform the input/output operation. This call is being done with the minor number as a parameter and it is entirely up to the driver how the minor number is being interpreted. The driver documentation usually describes how the driver uses minor numbers. For IDE disks, this documentation is in <tt>/usr/src/linux/Documentation/ide.txt</>. For SCSI disks, one would expect such documentation in <tt>/usr/src/linux/Documentation/scsi.txt</>, but it isn't there. One has to look at the driver source to be sure (<tt>/usr/src/linux/driver/scsi/sd.c:184-196</>). Fortunately, there is Peter Anvin's list of device numbers and names in <tt>/usr/src/linux/Documentation/devices.txt</>; see the entries for block devices, major 3, 22, 33, 34 for IDE and major 8 for SCSI disks. The major and minor numbers are a byte each and that is why the number of partitions per disk is limited. --> デバイスにアクセスする際には、入出力操作を行うためにどのデバイスドライ バを呼び出すのかをメジャーナンバーで選択する。この呼び出しはマイナーナ ンバーをパラメータとして行うが、このマイナーナンバーをどのように解釈す るのかは完全にドライバ次第である。ドライバに関する文書は普通、ドライバ がどのようにマイナー番号を使うかを記述しています。IDE ディスクではこの 文書は <tt>/usr/src/linux/Documentation/ide.txt</> にあります。SCSI ディ スクでは、<tt>/usr/src/linux/Documentation/scsi.txt</> にあると言いた いところですがここにはありません。ドライバのソースコードを見て下さい。 (<tt>/usr/src/linux/driver/scsi/sd.c:184-196</> にあります) 幸運にも Peter Anvin 氏によるデバイス番号とデバイス名のリストが <tt>/usr/src/linux/Documentation/devices.txt</> にあります。ブロックデ バイスのエントリを見て下さい。メジャー番号の 3, 22, 33, 34 が IDE ディ スクに、8 が SCSI ディスクにわりあてられています。メジャー/マイナー番 号はそれぞれ1バイトであり、それゆえディスクあたりのパーティションの数 に限りがあるのです。 <!-- By convention device files have certain names and many system programs have knowledge about these names compiled in. They expect your IDE disks to be named <tt>/dev/hd*</> and your SCSI disks to be named <tt>/dev/sd*</>. Disks are numbered a, b, c and so on, so <tt>/dev/hda</> is your first IDE disk and <tt>/dev/sda</> is your first SCSI disk. Both devices represent entire disks, starting at block one. Writing to these devices with the wrong tools will destroy the master boot loader and partition table on these disks, rendering all data on this disk unusable or making your system unbootable. Know what you are doing and, again, back up before you do it. --> 慣習によりデバイスファイルはある特定の名前を持ち、多くのシステムプログ ラム中にその名前がコンパイル時に埋め込まれています。 IDE ディスクには <tt>/dev/hd*</> という名前が、また SCSI ディスクには <tt>/dev/sd*</> という名前が想定されています。ディスクは a, b, c などと番号付けられ、 それゆえ <tt>/dev/hda</> は最初の IDE ディスクで、<tt>/dev/sda</> は最 初の SCSI ディスクです。この2つのデバイスはブロック1から始まるディス ク全てを表しています。これらのデバイスにまちがったツールで書き込みをお こなうとマスターブートローダーやディスクのパーティションテーブルが壊れ、 ディスク上の全てのデータが使えなくなり、システムが起動不能になります。 作業をする際には自分がしようとしていることを理解し、もう一度いいますが、 実行する前にバックアップをとってください。 <!-- Primary partitions on a disk are 1, 2, 3 and 4. So <tt>/dev/hda1</> is the first primary partition on the first IDE disk and so on. Logical partitions have numbers 5 and up, so <tt>/dev/sdb5</> is the first logical partition on the second SCSI disk. --> ディスクの基本パーティションは1, 2, 3, 4 です。つまり <tt>/dev/hda1</> は1つめのIDEディスクの1つめの基本パーティションです。論理パーティショ ンの番号は5からになります。つまり <tt>/dev/sdb5</> は 1台目の SCSI ハー ドディスクの1つめの論理パーティションです。 <!-- Each partition entry has a starting and an ending block address assigned to it and a type. The type is a numerical code (a byte) which designates a particular partition to a certain type of operating system. For the benefit of computing consultants partition type codes are not really unique, so there is always the probability of two operating systems using the same type code. --> それぞれのパーティションエントリには最初と最後のブロックを指し示すアド レスとファイル型が格納してあります。ファイル型はそのパーティションがオ ペレーティングシステムのどのファイル型かを示す数字(1バイト)です。コン ピュータコンサルタントにとっては稼ぎの種になることですが、パーティショ ンのファイル型番号は実際は唯一ではなく、それゆえ2つのオペレーティング システムが同じファイル型番号を使う可能性が常にあります。 <!-- Linux reserves the type code 0x82 for swap partitions and 0x83 for "native" file systems (that's ext2 for almost all of you). The once popular, now outdated Linux/Minix file system used the type code 0x81 for partitions. OS/2 marks it's partitions with a 0x07 type and so does Windows NT's NTFS. MS-DOS allocates several type codes for its various flavors of FAT file systems: 0x01, 0x04 and 0x06 are known. DR-DOS used 0x81 to indicate protected FAT partitions, creating a type clash with Linux/Minix at that time, but neither Linux/Minix nor DR-DOS are widely used any more. The extended partition which is used as a container for logical partitions has a type of 0x05, by the way. --> Linux はファイル型番号として 0x82 を、スワップパーティションとして 0x83をネイティブなファイルシステム(ほとんどすべての人にとってext2)とし て予約しています。以前は一般的でしたが今は古くなった Linux/Minix ファ イルシステムには 0x81 を割り当てています。OS/2 はそのパーティションに 0x07 をあて、その番号を Windows NT の NTFS も使っています。MS-DOS は FAT ファイルシステムのさまざまな味付けの違いのためにいくつかのファイル 型番号を割り当てています：0x01,0x04, 0x06 が知られています。DR-DOS は 0x81 を保護された FAT パーティションを指し示すのに使い、Linux/Minix と ともに使った場合に型による破壊を引きおこしましたが、もはや Linux/Minux と DR-DOS の双方を使うことは滅多にないでしょう。論理パーティションのた めのコンテナとして使われる拡張パーティションは0x05の型番号を持っていま す。 <!-- Partitions are created and deleted with the <tt>fdisk</> program. Every self respecting operating system program comes with an <tt>fdisk</> and traditionally it is even called <tt>fdisk</> (or <tt>FDISK.EXE</>) in almost all OSes. Some <tt>fdisk</>s, noteable the DOS one, are somehow limited when they have to deal with other operating systems partitions. Such limitations include the complete inability to deal with anything with a foreign type code, the inability to deal with cylinder numbers above 1024 and the inability to create or even understand partitions that do not end on a cylinder boundary. For example, the MS-DOS fdisk can't delete NTFS partitions, the OS/2 fdisk has been known to silently "correct" partitions created by the Linux fdisk that do not end on a cylinder boundary and both, the DOS and the OS/2 fdisk, have had problems with disks with more than 1024 cylinders (see the "large-disk" Mini-Howto for details on such disks). --> パーティションは <tt>fdisk</> プログラムで作成、削除を行ないます。自立 したすべてのオペレーティングシステムには <tt>fdisk</> が含まれ、伝統的 にほとんどすべての OS で fdisk (または <tt>FDISK.EXE</> )と呼ばれてさ えいます。いくつかの <tt>fdisk</> では（有名なのは DOS のものですが）、 他のオペレーティングシステムのパーティションを扱うときに制限があります。 制限とは、知らないファイル型番号持つものは扱えない事、1024より大きいシ リンダ数を扱えない事、シリンダ境界に終りがないパーティションを作成や認 識できない事、などがあります。例えば、MS-DOS の fdisk は NTFS パーティ ションを削除できませんし、OS/2 の fdisk では、Linux の fdisk によって 作成された、シリンダ境界で終っていないパーティションを「黙って修正」し てしまうことが知られています。また DOS と OS/2 の fdisk は1024シリンダ 以上を持つディスクを扱う際に問題がありました。(これらのディスクについ ての詳しい情報は"large-disk" Mini-Howtoを見て下さい。) <sect>私はどんなパーティションを必要としているのだろう？ <sect1>私に必要なパーティションの数は？ <p> <!-- Okay, so what partitions do you need? Well, some operating systems do not believe in booting from logical partitions for reasons that are beyond the scope of any sane mind. So you probably want to reserve your primary partitions as boot partitions for your MS-DOS, OS/2 and Linux or whatever you are using. Remember that one primary partition is needed as an extended partition, which acts as a container for the rest of your disk with logical partitions. --> OKay,ではどんなパーティションをあなたは必要としているのでしょう？論理 パーティションから起動することなど、頭から、全く考慮していないオペレー ティングシステムだってあります。だから、ひょっとするとMS-DOS, OS/2 や Linux や使っている OS の起動パーティションとして基本パーティションをとっ ておきたくなるかもしれません。1つの基本パーティションが、論理パーティ ション用の入れ物となる拡張パーティションとして必要となることをお忘れな く。 <!-- Booting operating systems is a real-mode thing involving BIOSes and 1024 cylinder limitations. So you probably want to put all your boot partitions into the first 1024 cylinders of your hard disk, just to avoid problems. Again, read the "large-disk" Mini-Howto for the gory details. --> オペレーティングシステムの起動はリアルモードで行われます。つまり BIOS と1024シリンダの制限が絡みます。そこで問題を避けるために、すべてのブー トパーティションをハードディスクの最初の1024シリンダ以内に置きたくなる かもしれません。もう一度よく "large-disk" Mini-Howto を読んでください。 <!-- To install Linux, you will need at least one partition. If the kernel is loaded from this partition (for example by LILO), this partition must be readable by your BIOS. If you are using other means to load your kernel (for example a boot disk or the LOADLIN.EXE MS-DOS based Linux loader) the partition can be anywhere. In any case this partition will be of type 0x83 "Linux native". --> Linux をインストールするために、少なくとも1パーティションが必要です。 カーネルがこのパーティションから読み込まれれるなら(例えばLILOによって)、 このパーティションは BIOS から読めなければなりません。他の方法でカーネ ルを読み込む場合(例えばブートディスクや MS-DOS から Linux を起動する LOADLIN.EXE など)、パーティションはどこにあってもいいです。あらゆる場 合においてこのパーティションはファイル型 0x83の"Linux native" にします。 <!-- Your system will need some swap space. Unless you swap to files you will need a dedicated swap partition. Since this partition is only accessed by the Linux kernel and the Linux kernel does not suffer from PC BIOS deficiencies, the swap partition may be positioned anywhere. I recommed using a logical partition for it (/dev/?d?5 and higher). Dedicated Linux swap partitions are of type 0x82 "Linux swap". --> システムにはいくらかのスワップ領域が必要です。ファイルにスワップをとる のでなければ、専用のスワップパーティションが必要になります。このパーティ ションは Linux カーネルによるアクセスのみで、Linux カーネルは PC BIOS の欠点に悩まされませんので、スワップパーティションはどこに置いてもかま いません。私は論理パーティション(/dev/?d?5より上)を使うことをお勧めし ます。専用のLinuxスワップパーティションはファイル型 0x82 "Linux swap" です。 <!-- These are minimal partition requirements. It may be useful to create more partitions for Linux. Read on. --> これらは最小限のパーティション構成です。Linux にとってはより多くのパー ティションを作ると便利かもしれません。以降を読んでください。 <sect1>スワップ領域はどのくらいの大きさがいいのだろう？ <p> <!-- If you have decided to use a dedicated swap partition, which is generally a Good Idea [tm], follow these guidelines for estimating its size: --> 専用のスワップパーティションを使うと決めた（普通これは 'Good Idea [tm]'ですが）場合、その大きさを見積もるのには以下のガイドラインを 使って下さい: <itemize> <!-- <item> In Linux RAM and swap space add up (This is not true for all Unices). For example, if you have 8 MB of RAM and 12 MB swap space, you have a total of about 20 MB virtual memory. --> <item>Linux では RAM とスワップ領域は加算されます(これは全ての Unix で 正しいわけではありません)。例えば 8MB の RAM と 12MB のスワップ領域が あれば、あわせて 20MB の仮想メモリが使えます。 <!-- <item> When sizing your swap space, you should have at least 16 MB of total virtual memory. So for 4 MB of RAM consider at least 12 MB of swap, for 8 MB of RAM consider at least 8 MB of swap. --> <item>スワップ領域のサイズを決める時、総仮想メモリを少なくとも 16MB は とるべきです。つまり 4MB の RAM のときは少なくとも 12MB のスワップを作 り、8MB の RAM のときは少なくとも 8MB のスワップを作るべきです。 <!-- <item> In Linux, a single swap partition can not be larger than 128 MB. That is, the partition may be larger than 128 MB, but excess space is never used. If you want more than 128 MB of swap, you have to create multiple swap partitions. --> <item>Linuxでは1つのスワップパーティションは 128MB 以上とれません。言 い換えれば、パーティションそのものは 128MB より大きくできますが、 128MB を超えた分は決して使われないのです。もし 128MB 以上のスワップを 確保したいときは、複数のスワップパーティションを作らなければなりません。 <!-- <item> When sizing swap space, keep in mind that too much swap space may not be useful at all. --> <item>スワップ領域のサイズを決める時、あまりにスワップ領域を取りすぎて も、その分は全く役に立たないことに留意してください。 <!-- Every process has a "working set". This is a set of in-memory pages which will be referenced by the processor in the very near future. Linux tries to predict these memory accesses (assuming that recently used pages will be used again in the near future) and keeps these pages in RAM if possible. If the program has a good "locality of reference" this assumption will be true and prediction algorithm will work. --> すべてのプロセスは「ワーキングセット」を持っています。これはすぐにでも プロセッサによって参照されうる、ページアウトされていなく、実メモリ上にあ るページのセットです。Linux は、これらのメモリアクセスを「直前に使った ページほど使われやすい」という仮定のもとに予測し、可能な限りこれらを 実メモリ上のページに残しておこうとします。もしプログラムの「局所参照性」 が良い場合には、この仮定は正しく、予想アルゴリズムは有効に働くでしょう。 <!-- Holding a working set in main memory does only work if there is enough main memory. If you have too many processes running on a machine, the kernel is forced to put pages on disk that it will reference again in the very near future (forcing a page-out of a page from another working set and then a page-in of the page referenced). Usually this results in a very heavy increase in paging activity and in a sustantial drop of performance. A machine in this state is said to be "thrashing" (For you german readers: That's "thrashing" ("dreschen", "schlagen", "haemmern") and not trashing ("muellen")). --> 作業領域がメインメモリにとどまっていられるのは、メモリが十分あるときだ けです。マシン上で走るプロセスが多すぎると、カーネルは、あとですぐ使わ れるはずのページをディスク上に追い出して、必要なページをディスクから読 み出してくるという（無駄な）動作をせざるを得ないことになります。この結 果、ページングの異常な増加を招き、性能が著しく低下します。これが、いわ ゆる「スラッシング(thrashing)」と呼ばれる状態です。（ドイツ人の読者の ために補足：これは "thrashing" （"dreschen", "schlagen", "haemmern"） のことで "trashing" （"muellen") のことではありません。） <!-- On a thrashing machine the processes are essentially running from disk and not from RAM. Expect performance to drop by approximately the ratio between memory access speed and disk access speed. --> スラッシング状態のマシンでは実質的にプロセスが RAM 上でなくディスク上 で動いています。従って予測される性能の低下は、だいたいメモリアクセスの 速度とディスクアクセスの速度の比となります。 <!-- A very old rule of thumb in the days of the PDP and the Vax was that the size of the working set of a program is about 25% of its virtual size. Thus it is probably useless to provide more swap than three times your RAM. --> PDP や Vax の時代のとても古い経験則ではプログラムのワーキングセットの サイズはその仮想サイズのおよそ25%でした。それゆえRAMの３倍以上のスワッ プは、意味がありません。 <!-- But keep in mind that this is just a rule of thumb. It is easily possible to create scenarios where programs have extremely large or extremely small working sets. For example, a simulation program with a large data set that is accessed in a very random fashion would have almost no noticeable locality of reference in its data segment, so its working set would be quite large. --> しかし、これは経験則でしかないということを覚えておいてください。あるプ ログラムのワーキングセットが非常に大きいとか、あるいはとても小さい、な んてことはしょっちゅうあります。例えば、非常にさまざまな方法でアクセス される大きなデータセットを扱うシミュレーションプログラムでは、そのデータ セグメント中に局所参照性はほとんど存在しません。したがって、 そのワーキングセットは非常に大きいでしょう。 <!-- On the other hand, an xv with many simultaneously opened JPEGs, all but one iconified, would have a very large data segment. But image transformations are all done on one single image, most of the memory occupied by xv is never touched. The same is true for an editor with many editor windows where only one window is being modified at a time. These programs have - if they are designed properly - a very high locality of reference and large parts of them can be kept swapped out without too severe performance impact. --> 一方、同時にたくさんの JPEG ファイルを開いた、しかし1つを除いてアイコ ン化された xv は非常に大きなデータセグメントを持ちます。しかし、全ての イメージ変換は(同時には)1つのイメージでのみなされているので xv で占め られるメモリーのほとんどは扱われていません。同じことがエディットウイン ドウをたくさん開いた、しかも同時に変更するのは1つのウインドウのみとい うエディタにもあてはまります。これらのプログラムは(もしもそれらが正し く設計されていたら)とてもたかい局所参照性を持ち、パフォーマンスにそ れほど重大な影響をあたえずにそれらの多くの部分をスワップアウトしておけ ます。 <!-- One could suspect that the 25% number from the age of the command line is no longer true for modern GUI programs editing multiple documents, but I know of no newer papers that try to verify these numbers. --> コマンドラインの時代からの 25% という数字は、複数のドキュメントを編集 するような現代の GUI プログラムにとってもはや正しくないと予想できます。 しかし、これらの数字を確かめようとする新しい文書をみたことはありません。 </itemize> <!-- So for a configuration with 16 MB RAM, no swap is needed for a minimal configuration and more than 48 MB of swap are probably useless. The exact amount of memory needed depends on the application mix on the machine (what did you expect?). --> ですから 16MB RAM のばあい、最小限の設定ではスワップは必要ではないし、 48MB を越えるスワップはたぶん無用でしょう。正確な必要メモリ量はマシン 上のアプリケーションによります。(なにを期待してたんですか？) <sect1>どこにスワップスペースを置くべきか？ <p> <itemize> <!-- <item> Mechanics are slow, electronics are fast. --> <item>メカニクスは遅く、エレクトロニクスは速い。 <!-- Modern hard disks have many heads. Switching between heads of the same track is fast, since it is purely electronic. Switching between tracks is slow, since it involves moving real world matter. --> 最近のハードディスクはたくさんのヘッドを持っています。同じトラックのヘッ ド間のスイッチは高速です。それはそれが純粋に電気的なことだから です。トラック間のスイッチは低速です、それは現実の物質世界中を動くから です。 <!-- So if you have a disk with many heads and one with less heads and both are identical in other parameters, the disk with many heads will be faster. --> なので、ヘッドの多いディスクとヘッドの少ないディスクを比べると、他の要 素が同一の場合、多くのヘッドを持つディスクの方が高速でしょう。 <!-- Splitting swap and putting it on both disks will be even faster, though. --> しかし、スワップを分割し、双方のディスクに配置するとさらに速くなります。 <!-- <item> Older disks have the same number of sectors on all tracks. With this disks it will be fastest to put your swap in the middle of the disks, assuming that your disk head will move from a random track towards the swap area. --> <item>昔のディスクには全てのトラック上に同じ数のセクタがありました。こ のようなディスクの場合、ディスクヘッドがランダムなトラックからスワッ プ領域に移動することを考えると、スワップをディスクの真中に置くと最も高 速です。 <!-- <item> Newer disks use ZBR (zone bit recording). They have more sectors on the outer tracks. With a constant number of rpms, this yields a far greater performance on the outer tracks than on the inner ones. Put your swap on the fast tracks. --> <item>最近のディスクでは ZBR (zone bit recording）が用いられています。 これは外側のトラックにたくさんセクタを配置します。したがって回転速度が 一定なら、外側のトラックは内側に比べてずっと性能が高くなります。スワッ プは高速なトラックに配置しましょう。 <!-- <item> Of course your disk head will not move randomly. If you have swap space in the middle of a disk between a constantly busy home partition and an almost unused archive partition, you would be better of if your swap were in the middle of the home partition for even shorter head movements. You would be even better off, if you had your swap on another otherwise unused disk, though. --> <item>もちろんディスクヘッドは必ずしもランダムに動くわけではありません。常に 忙しい home パーティションの真中と、ほとんど使われない保管用パーティショ ンの真中にスワップ領域を取った場合をくらべれば、ヘッドの動きが最小で済 む home パーティション の真中にスワップがあるほうがより高速です。まあ、 もう一方の使ってないディスク上にもスワップがあればより速いですが。 </itemize> <!-- <bf/Summary:/ Put your swap on a fast disk with many heads that is not busy doing other things. If you have multiple disks: Split swap and scatter it over all your disks or even different controllers. --> <bf/まとめ：/他の仕事に忙しくなく、多くのヘッドを持った、高速なディス ク上にスワップ領域を取りましょう。複数のディスクを持っているとき：全て のディスク上、異なるコントローラがあればそれらでもスワップを分割、分散 しましょう。 <!-- <bf/Even better:/ Buy more RAM. --> <bf/さらに良い方法：/RAMをもっと買いましょう。 <sect1>ファイルシステムとフラグメンテーションに関するいくつかの事実 <p> <!-- Disk space is administered by the operating system in units of blocks and fragments of blocks. In ext2, fragments and blocks have to be of the same size, so we can limit our discussion to blocks. --> ディスクスペースはオペレーティングシステムによってブロック単位やブロッ クのフラグメントで管理されています。ext2 ではフラグメントとブロックは 同じサイズでなければなりません。そこでわれわれは議論をブロックに限るこ とができます。 <!-- Files come in any size. They don't end on block boundaries. So with every file a part of the last block of every file is wasted. Assuming that file sizes are random, there is approximately a half block of waste for each file on your disk. Tanenbaum calls this "internal fragmentation" in his book "Operating Systems". --> ファイルはいかなるサイズでもありえます。それらはブロック境界では終りま せん。そこで全てのファイルではファイルの最後のブロックの一部が無駄とな ります。ファイルサイズが不規則だとすれば、ディスク上のファイルのそれぞ れにブロックの半分の(サイズの)無駄があると予想できます。Tanenbaum 教授 はこれを"Operating Systems"のなかで"internal fragmentation"と呼んでい ます。 <!-- You can guess the number of files on your disk by the number of allocated inodes on a disk. On my disk --> ディスク上で占められるinodeの数からファイル数が推測できます。私の場合 は： <tscreen><code> # df -i Filesystem Inodes IUsed IFree %IUsed Mounted on /dev/hda3 64256 12234 52022 19% / /dev/hda5 96000 43058 52942 45% /var </code></tscreen> <!-- there are about 12000 files on <tt>/</> and about 44000 files on <tt>/var</>. At a block size of 1 KB, about 6+22 = 28 MB of disk space are lost in the tail blocks of files. Had I chosen a block size of 4 KB, I had lost 4 times this space. --> 約12000のファイルが<tt>/</>(ルート)に、約44000のファイルが<tt>/var</> にあります。1 KBのブロックサイズでは 6+22 = 28 MB のディスク容量がファ イルの尻尾の部分として失われています。ブロックサイズを 4KB とした場合、 この容量の4倍を失うことになります。 <!-- Data transfer is faster for large contiguous chunks of data, though. That's why ext2 tries to preallocate space in units of 8 contigous blocks for growing files. Unused preallocation is released when the file is closed, so no space is wasted. --> データ転送速度はおおきくて連続したデータのかたまりのほうが速いです。そ こで ext2 はサイズが大きくなりつつあるファイルのために8つの連続したブ ロックごとにあらかじめ領域を割り当てようとします。あらかじめとっておい た領域の使われない部分はこのファイルが閉じられたときに解放されます。 <!-- Noncontiguous placement of blocks in a file is bad for performance, since files are often accessed in a sequential manner. It forces the operating system to split a disk access and the disk to move the head. This is called "external fragmentation" or simply "fragmentation" and is a common problem with DOS file systems. --> 1つのファイルが不連続なブロックに配置されているのはパフォーマンスの点 でよくないことです。なぜならファイルはしばしば連続的にアクセスされるか らです。ファイルが不連続だとオペレーティングシステムにディスクアクセス を分割しなければならず、ディスクはヘッドを動かさなければなりません。こ れは"external fragmentation"とか単純に"フラグメンテーション (fragmentation)"と呼ばれ DOSファイルシステム上と共通の問題です。 <!-- ext2 has several strategies to avoid external fragmentation. Normally fragmentation is not a large problem in ext2, not even on heavily used partitions such as a USENET news spool. While there is a tool for defragmentation of ext2 file systems, nobody ever uses it and it is not up to date with the current release of ext2. Use it, but do so on your own risk. --> ext2 は external fragmentation を避けるためにいくつかの戦略を持ってい ます。普通、フラグメンテーションは USENET ニューススプールの様に酷使さ れない限り、ext2 にとって大きな問題ではありません。ext2 ファイルシステ ム用のデフラグツールがあるのですが、ext2 の現リリースに追い付いていま せん。これを使うときは、自分の責任で行ってください。 <!-- The MS-DOS file system is well known for its pathological managment of disk space. In conjunction with the abysmal buffer cache used by MS-DOS the effects of file fragmentation on performance are very noticeable. DOS users are accustomed to defragging their disks every few weeks and some have even developed some ritualistic beliefs regarding defragmentation. None of these habits should be carried over to Linux and ext2. Linux native file systems do not need defragmentation under normal use and this includes any condition with at least 5% of free space on a disk. --> MS-DOS ファイルシステムはディスクスペースの異常な管理でよく知られてい ます。MS-DOS のバッファキャッシュの使い方がひどく悪いことと相まってパ フォーマンスに及ぼすファイルフラグメンテーションの影響は際だっています。 DOS ユーザー達はほとんど毎週ディスクをデフラグすることに慣れていて、デ フラグすることに関して儀式的な信仰に達している人すらいます。このような 習慣は Linux と ext2 に持ちこむべきではありません。Linux のネイティブ なファイルシステムは普通の使い方ではデフラグを必要としません。ディスク 上の空き領域がすくなくとも 5% ある状況なら「普通の使い方」の範疇です。 <!-- The MS-DOS file system is also known to lose large amounts of disk space due to internal fragmentation. For partitions larger than 256 MB, DOS block sizes grow so large that they are no longer useful (This has been corrected to some extent with FAT32). --> MS-DOS ファイルシステムはまた、internal fragmentation によりディスク領 域の大きな部分を失うことも知られています。256MB より大きなパーティショ ンでは DOS のブロックサイズはもはや使い難いほど大きくなります。(このこ とは FAT32 による拡張などにもあてはまります) <!-- ext2 does not force you to choose large blocks for large file systems, except for very large file systems in the 0.5 TB range (that's terabytes with 1 TB equaling 1024 GB) and above, where small block sizes become inefficient. So unlike DOS there is no need to split up large disks into multiple partitions to keep block size down. Use the 1 KB default block size if possible. You may want to experiment with a block size of 2 KB for some partitions, but expect to meet some seldom exercised bugs: Most people use the default. --> ext2 は、小さなブロックサイズが役立たずになる0.5TB (テラバイトと読み 1TB は 1024GB になります)とかそれ以上の巨大なファイルシステム以外は、 大きなファイルシステムのために大きなブロックサイズを選ばなければならな い、ということはありません。ですので DOS と違って、ブロックサイズを小 さくするために大きなディスクを複数のパーティションに分ける必要はありま せん。可能ならば、デフォルトのブロックサイズ 1KBを使ってください。いく つかのパーティションを実験的に 2KB のブロックサイズにしてみたくなるか もしれませんが、まれなバグに遭遇することを覚悟しておいてください。ほと んどの人がデフォルトを使っているので。 <sect1>パーティション分けの判断基準となるファイル寿命とバックアップサイクル <p> <!-- With ext2, Partitioning decisions should be governed by backup considerations and to avoid external fragmentation from different file lifetimes. --> ext2 のもとでは、パーティション分けはバックアップを考慮したり異なるファ イル寿命から生じる external fragmentation を避けるためなどから決めるべ きです。 <!-- Files have lifetimes. After a file has been created, it will remain some time on the system and then be removed. File lifetime varies greatly throughout the system and is partly dependent on the pathname of the file. For example, files in <tt>/bin</>, <tt>/sbin</>, <tt>/usr/sbin</>, <tt>/usr/bin</> and similar directories are likely to have a very long lifetime: many months and above. Files in <tt>/home</> are likely to have a medium lifetime: several weeks or so. File in <tt>/var</> are usually short lived: Almost no file in <tt>/var/spool/news</> will remain longer than a few days, files in <tt>/var/spool/lpd</> measure their lifetime in minutes or less. --> ファイルには寿命があります。ファイルが作られたあと、それはしばらくシス テム上に保持され、のちに削除されます。ファイルの寿命はシステム内で様々 ですし、ある程度ファイルのパスに依存します。例えば、<tt>/bin</>, <tt>/sbin</>, <tt>/usr/sbin</>, <tt>/usr/bin</> とか同じようなディレク トリ中のファイルはおそらく大変長い寿命(数ヶ月とかそれ以上)を持つでしょ う。<tt>/home</> のファイルは数週間かそこらの中くらいの寿命を持つでしょ う。<tt>/var</> のファイルは普通、寿命が短いです。 <tt>/var/spool/news</> 中のファイルは数日以上は残らないでしょう。 <tt>/var/spool/lpd</> 中のファイルは数分とかそれ以下の単位で寿命が計れ ます。 <!-- For backup it is useful if the amount of daily backup is smaller than the capacity of a single backup medium. A daily backup can be a complete backup or an incremental backup. --> もし「デイリーバックアップ」の量がバックアップメディア1枚の容量以下な らばバックアップはやりやすいです。「デイリーバックアップ」とはフルバッ クアップまたはインクリメンタルバックアップです。 <!-- You can decide to keep your partition sizes small enough that they fit completely onto one backup medium (choose daily full backups). In any case a partition should be small enough that its daily delta (all modified files) fits onto one backup medium (choose incremental backup and expect to change backup media for the weekly/monthly full dump - no unattended operation possible). --> パーティションサイズを1枚のバックアップメディアに収まるように、 十分小さくしておくようにすることもできます(毎日フルバックアップするよ うにしましょう) 。そうでない場合でも、パーティションは毎日の増加分(変 更された全てのファイル)が1枚のバックアップメディアに十分収まる程度の 大きさにしておくべきです。(インクリメンタルバックアップを選択し、毎週／ 毎月のフルバックアップ -無人では作業できないバックアップ- の度にバック アップメディアを交換するようにしましょう)。 <!-- Your backup strategy depends on that decision. --> あなたのバックアップ戦略はこれらの決定に依存しています。 <!-- When planning and buying disk space, remember to set aside a sufficient amount of money for backup! Unbackuped data is worthless! Data reproduction costs are much higher than backup costs for virtually everyone! --> ディスク領域に関し計画したり、ディスクを購入するときは、バックアップの ために十分なお金を用意することに留意しておいてください。バックアップさ れていないデータは価値がないのです！データを作り直すコストはほとんどす べての人にとってバックアップのコストよりずっと大きいのです。 <!-- For performance it is useful to keep files of different lifetimes on different partitions. This way the short lived files on the news partition may be fragmented very heavily. This has no impact on the performance of the <tt>/</> or <tt>/home</> partition. --> 異なった寿命を持つファイルを異なったパーティションに置いておくのはパフォー マンスにとってよいことです。このやりかただとニュースパーティション上の 短命なファイルはフラグメントが大きいです。このことが <tt>/</> や <tt>/home</> パーティションのパフォーマンスに影響をおよぼすことはあり ません。 <sect>例 <sect1>意欲のある初心者のための推奨モデル <p> <!-- A common model creates <tt>/</>, <tt>/home</> and <tt>/var</> partitions as discussed above. This is simple to install and maintain and differentiates well enough to avoid adverse effects from different lifetimes. It fits well into a backup model, too: Almost noone bothers to backup USENET news spools and only some files in <tt>/var</> are worth backing up (<tt>/var/spool/mail</> comes to mind). On the other hand, <tt>/</> changes infrequently and can be backuped upon demand (after configuration changes) and is small enough to fit on most modern backup media as a full backup (plan 250 to 500 MB depending on the amount of installed software). <tt>/home</> contains valuable user data and should be backuped daily. Some installations have very large <tt>/home</>s and must use incremental backups. --> 一般的なモデルでは <tt>/</>, <tt>/home</>, <tt>/var</> パーティション を上記のように作成します。このことはインストールや維持を単純なものにし、 ファイル寿命の違いからくる不都合な点を避けるのに十分な区分けです。これ はバックアップモデルにもよくあてはまります。ほとんどの人は USENET ニュー ススプールはバックアップしないでしょうし、<tt>/var</> の中でバックアッ プする価値があるのはいくつかのファイルだけでしょう (<tt>/var/spool/mail</> が思い浮かぶでしょう)。一方、<tt>/</> はあまり 変更されませんから、必要なときにだけ(設定を変更したあとだけ)バックアッ プすれば良いでしょう。またほとんどの現代的なバックアップメディアにフル バックアップできるほど十分小さいです。(インストールするソフトウェアの 大きさによって250から500MB割り当てましょう)。<tt>/home</> は変化するユー ザーデータが含まれるので毎日バックアップすべきです。インストール状態に よっては巨大な <tt>/home</> があり、インクリメンタルバックアップをしな ければなりません。 <!-- Some systems put <tt>/tmp</> onto a seperate partition as well, others symlink it to <tt>/var/tmp</> to achieve the same effect (note that this can affect single user mode, where <tt>/var</> will be unavailable and the system will have no <tt>/tmp</> until you create one or mount <tt>/var</> manually) or put it onto a RAM disk (Solaris does this for example). This keeps <tt>/tmp</> out of <tt>/</>, a good idea. --> そのうえ、<tt>/tmp</> を 分割したパーティションに置いているシステムも あります。また別のシステムでは <tt>/var/tmp</> にシンボリックリンクを はったり(これはシングルユーザーモードに影響を及ぼし、手動で <tt>/tmp</> を1つ作るか <tt>/var</> をマウントするまでシステムは <tt>/tmp</> を持たないことに注意)、RAM ディスクにそれを置くことで(たと えば Solalis がこれ)同様の効果を狙っています。 このことは <tt>/</> の そとに <tt>/tmp</> を置いておけるので良い考えです。 <!-- This model is convenient for upgrades or reinstallations as well: Save your configuration files (or the entire <tt>/etc</>) to some <tt>/home</> directory, scrap your <tt>/</>, reinstall and fetch the old configurations from the save directory on <tt>/home</>. --> 加えて、このモデルはアップグレードや再インストールの場合も便利です：設 定ファイル(または <tt>/etc</> 全体)を <tt>/home</> ディレクトリのどこ かに保存しておけば、 <tt>/</> の再生や、再インストール、古い設定を <tt>/home</> にある保存しておいたディレクトリから取り出す、などができ ます。 <sect>私の場合 <p> <!-- There was this old ISA bus 386/40 sitting on my shelf that I abandoned two years ago because it no longer cut it. I was planning to turn it into a small X-less server for my household LAN. --> ここに古い ISA バスの 386/40 マシンがもう取り上げるものもなく棚に2年 まえから放棄されていました。で、家庭内LANのために簡素なXなしのサーバに 変身させることを考えました。 <!-- Here is how I did it: I took that 386 and put 16 MB RAM into it. Added a cheap EIDE disk, the smallest I could get (800 MB) and an ethernet card. Added an old Hercules because I still had a monitor for it. Installed Linux on it and there I have my local NFS, SMB, HTTP, LPD/LPR and NNTP server as well as my mail router and POP3 server. With an additional ISDN card the machine became my TCP/IP router and firewall, too. --> 以下、私のやったことです： 386 を手にいれ 16MB RAM をのせました。安く て今手にはいる最小の (800MB)EIDE ディスクとイーサネットカードを追加し ました。さらに古いヘラクレスのビデオカードを追加しました。それにつなげ るモニターがあったからです。 Linux をインストールすれば、ローカルな NFS, SMB, HTTP, LPD/LPR, NNTP サーバーの出来上がりです。メールサーバや POP3 サーバにもできます。別のモデムや ISDN カードがあれば TCP/IP ルー タやファイアウォールにもなります。 <!-- Most of the disk space on this machine went into the <tt>/var</> directories, <tt>/var/spool/mail</>, <tt>/var/spool/news</> and <tt>/var/httpd/html</>. I put <tt>/var</> on a separate partition and made this one large. There will be almost no users on this machine, so I created no home partition and mounted <tt>/home</> from some other workstation via NFS. --> このマシンで使われるディスク領域のほとんどは <tt>/var</> ディレクトリ にあります。 <tt>/var/spool/mail</>, <tt>/var/spool/news</>, <tt>/var/httpd/html</> などです。<tt>/var</> を分離したパーティション に置き、これに大きな領域をあてがいます。このマシン上にはほとんどユーザー 領域はいらないので、 <tt>/home</> は作らず他のワークステーションから NFS でマウントしました。 <!-- Linux without X plus several locally installed utilities will be fine with a 250 MB partition as <tt>/</>. The machine has 16 MB of RAM, but it will be running many servers. 16 MB swap should be in order, 32 MB should be plenty. We are not short on disk space, so the machine will get 32 MB. Out of sentimentality a MS-DOS partition of some 20 MB is kept on it. I decided to import <tt>/home</> from another machine, so the remaining 500+ MB will end up as <tt>/var</>. This is more than sufficient for a household USENET news feed. --> X といくつかのユーティリティをのぞいた Linux システムは <tt>/</> にあ てがった 250MB のパーティションに充分入るでしょう。このマシンは 16 MB の RAM を持っていますが多くのサーバーを動かします。 16MB のスワップが おそらく必要で、32MB あれば十分でしょう。ここではディスクスペースが不 足しているわけではないので32MBとします。センチメンタルな気分は捨てて、 MS-DOS パーティションは20MBぐらいにしました。他のマシンから <tt>/home</> をインポートすると決めたので、500MB以上 <tt>/var</> とし て残ります。これなら家庭内 USENET ニュースサービスとしては十分以上でしょ う。 <!-- We get --> でこうなりました。 <tscreen><code> Device Mounted on Size /dev/hda1 /dos_c 25 MB /dev/hda2 - (Swapspace) 32 MB /dev/hda3 / 250 MB /dev/hda4 - (Extended Container) 500 MB /dev/hda5 /var 500 MB homeserver:/home /home 1.6 GB </code></tscreen> <!-- I am backing up this machine via the network using the tape in <tt>homeserver</>. Since everything on this machine has been installed from CD-ROM all I have to save are some configuration files from <tt>/etc</>, my customized locally installed *.tgz files from <tt>/root/Source/Installed</> and <tt>/var/spool/mail</> as well as <tt>/var/httpd/html</>. I copy these files into a dedicated directory <tt>/home/backmeup</> on <tt>homeserver</> every night, where the regular homeserver backup picks them up. --> バックアップは<tt>ホームサーバー</>のテープを用いてネットワーク経由で おこないます。このマシン上の全ては CD-ROM からインストールしたものなの で、保存しておかなければならないのは カスタマイズした <tt>/etc</> 以下 の設定ファイル や <tt>/root/Source/Installed</> からインストールした *.tgz ファイル、<tt>/var/spool/mail</> 、<tt>/var/httpd/html</> などだ けです。これらのファイルを毎晩<tt>ホームサーバー</>の <tt>/home/backmeup</> にコピーします。そうすればホームサーバーのバック アップの際、それらもバックアップできます。 </article> <!-- TODO: - Explain fdisk - Explain the ext2 utilities (get current versions first) - Explain the creation of new file systems - Explain mounting and unmounting file systems - Explain backup procedures -->