<!doctype linuxdoctr system>

<!-- This part is just my list of upcoming keywords. Do you really read this??
Need ext2fs aux progs: resize etc.
Partition: reasons: security, overflow protection; examples; flags.
nuni


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Changelog:
	140197: Added Copyright, disclaimer
	190197: cabling, ultra-2, OS types     
	22    : more OS, clustering
	27    : more clustering, implementation
	30    : more clustering, more implementation
	0202  : correct typos
	03    : added 'bits and pieces'
	05    : new: maintenance
	08    : new: Sun SPARC Solaris 2.5.1 setup
	09    : new: partitioning suggestion table
	10    : updates, tidying up ===> 0.12
	1603  : upd. for rel., CLV/CAV, mnt.mountpoint, dpt, prjs, numbering
		Debian 1.2.6 sizes
	23    : minor corrections, updates etc.
	0205  : more minor typos corrected and links added.
	1905  : more minor typos corrected and links added.
		(TheRef, WWW-FAQ, SCSI, Storage), unreleased.
	2505  : cleaning links and adding section on heat and links for webbing and home pages.
	2605  : Adding more info on CD-ROM file formats.
		Released as 0.13
	0506  : More on maintenance and misc formatting
	0806  :	Released as 0.13a
	2206  :	updated info on Dejanews, more on multi channel systems, released as 0.13b
	1207  :	updated info on Dejanews, released as 0.13c
	1108  : adding many references, one FAQ, credit name update, unreleased
	1208  : adding advanced chapter and notes on geometry
	1308  : Released as 0.14 in time for Yggdrasil print deadline
	1209  : Patch from kris, other inputs from edick and pot, tidying up ==>0.15
	2409  : Minor editing to clean up the index page ==>0.15a
	0510  : Fixing typos, cleaning up details on mailing lists ==>0.15b
	0610  : Changed more info section to use sections rather than itemizing,
	"	added section on online resources,
	"	added new chapter on how to get help efficiently ==>0.16
	1510  : Cleaned up tilde characters, added transfer speed table,
		new sect2 on maintenance deletions, info from /proc ==>0.16a
	2110  : Updated some links, more info on swap from Nakano-san,
		performance tuning link for INN ==>0.16b
	0511  : Updated some links, more info on HW RAID and benchmarks
		preparing for LSL release ==>0.16c
	0911  : Spam protection for all e-mail addresses but the author's ==>0.16d
	2811  : Minor corrections, cleaned up KB, MB, GB and added info on e2compr 
		Finally removed the 'mini_' from the title! ==>0.16e
	1012  : Added link to the new DPT RAID Howto. ==>0.16f
	030298: More on tmpfs, booting, hdparm, ext2fs docs, Win (sysedit, regedit)
	1202  : Merged in indexing from Redhat


	1105  : Major overhaul after major system update, now using SGMLtools-1.0.5 on Debian 1.3. This is going to be messy!
		- latency, fips32, reading plan, single drive partition, credits, new coordinator, SCSI arb pri, scsidev maj min numbering, devfs, more on swap, drive cache, FHS2.1
12(b):latency
21(c):credits, codename
	1907  : Minor corrections.
	0908  : Added example tables for systems with 1,2 and 4 ( opt RAID) drives
	3008  : General cleanup
	1009  : Gen. cleanup, capitalising headings and more acknowledgements
        0111  : New translations, more fs notes and some minor editing
	0311  : More fs related information

	0811  : Major rearrangement of document, restructuring chapter on "Considerations", adding more "Recommendations" and more on file systems ->0.20
	0922  : Major rearrangement continues  ->0.20a
	1217  : ...and continues  ->0.20b
	020199: ...and continues  ->0.20c A new year starts...
	1001  : More on fs ->0.20d and ->0.20e
	1601  : More on read-only fs ->0.20f
	1701  : More on networking fs ->0.20g (brief)
	1801  : ... and continues  ->0.20h
	2001  : More on special fs ->0.20i
	2301  : ... and continues plus some cleaning up ->0.20j and ->0.20k
	2401  : Cleaning up ->0.20l and add back 'considerations' ->0.20m

	2501  : Cleaning up the Implementation chapter ->0.21
	2601  : ... and continues, adding more credits too  ->0.21a ->0.21b
	2601  : Fold in patches from Nakano-san. Manually. ->0.22
	0102  : update release name, add minor details and fix typo ->0.22a
	0102  : Add more links ->0.22b
	0802  : Corrected bad typo, cleaned up header ->0.22c
	1602  : Links to benchmarking, Sun info, fixed mount data ->0.22d
	0703  : Fixed one link, better finger link, added BFS info ->0.22e
	1804  : Renames to Metalab, added efs, more on FIPS and term ->0.22f
	2804  : Added GFS ->0.22g
	2405  : Added Userfs, Arla, FSresearch, new mirror
	2705  : Corrected typo in mirror, added Software RAID HOWTO link
	1807  : Many corrections from N.T. Added update on Chinese translation.
	2507  : Added more on RAID, SCSI 160/m, smugfs, silicon disks and benchmarking ->022k
	1808  : Added info on xfs, ext3fs, DVD and ShowFAT ->022l
	2508  : Added info on Partition Resizer, fixed typos ->022m
	1909  : Added numerous updates on file systems and disk tech ->0.23
	2009  : Minor typos fixed ->0.23a
	2009  : Added catch on mount-linking. Numerous minor typos fixed ->0.23b
	3110  : Updates on SCSI/160, extfs growth and Italian translation ->0.23c
	0711  : Fixed small typo ->0.23d
	1211  : More on partition utilities ->0.23e
	230100: More on partition utilities and fix a typo ->0.23f

	0502  : Major upgrade based on inputs from schuulegaa (at) gatekeeper.txl.com ->0.24
	1403  : Continuing the above ->0.24a
	0203  : Continuing the above ->0.24b
	3004  : Continuing the above ->0.24c

	0105  : Various user inputs ->0.25
	0105  : Various minor changes ->0.25a
	0105  : Update with results from linkchecking ->0.25b
	0205  : Update with results from linkchecking ->0.25c
	0305  : Update with results from linkchecking ->0.25d
	0305  : Update with results from linkchecking ->0.25e

	2105  : Doc submitted to FHS list. Got one input there and some from translators ->0.30

	2206  : Added link to JFFS, updated and corrected links ->0.30a
	1907  : Added subsection on advanced mount options ->0.30b
	1907  : Replace file tags with hyperlinks ->0.30c

	2407  : Fixed a typo, sent in to ldp-submit ->0.31

	2009  : User inputs to file systems and FEM correction ->0.32
	1610  : Minor updates and release ->0.32a
	0511  : Fixed one typo and added link to scsidev development page ->0.32b
	1711  : Fixed typos and some links ->0.32c
	0312  : Another round of link checking, will this never end? ->0.32d
	1012  : Evidently not, more links updated -> 0.32e


 -->
<!--Import & Track 方式に移行 19991211 nakano -->


<article>


<!-- Title information -->
<!-- Old:  <title>Mini_HOWTO: Multi Disk System Tuning -->


<title>HOWTO: Multi Disk System Tuning
<author>Stein Gjoen, <tt/sgjoen@nyx.net/
<date>v0.32e , 10 December 2000
<trans>中野武雄 <tt/nakano@apm.seikei.ac.jp/
<tdate>v0.32ej1, 10 January 2000
<abstract>
<nidx>disk</nidx>
<nidx>partitions, disk (see disk)</nidx>
<!--O
This document describes how best to use multiple disks and partitions
for a Linux system. Although some of this text is Linux specific the
general approach outlined here can be applied to many other multi tasking
operating systems.
-->
この文書は Linux システムで複数のディスクやパーティションを最適に運用
するための方法について述べたものです。この文書の一部の話題は Linux に特有の
ものですが、用いているアプローチは一般的なものですから、
他の様々なマルチタスク OS にも適用できます。
</abstract>



<!-- Table of contents -->
<toc>

<!-- Begin the document -->

<!--	Old header follows
	Mini_HOWTO: Multi Disk System Tuning

	Version 0.7b	(Yes, that right: this is a BETA)
	Date 960823
	By Stein Gjoen <sgjoen@nyx.net>
 -->


<!--O
<sect>Introduction
-->
<sect>はじめに

<p>
<nidx>disk!introduction</nidx>
<!-- In commemoration of the "<it/Linux Hacker V2.0 - The New Generation/" this
brand new release is code named the <bf/Patricia Miranda/ release.  -->
<!-- After all, socks comes in pairs...
After all, this is a growing project... -->
<!-- In commemoration of recent legal development this
brand new release is code named the <bf/Trademark Resolution/ release.  -->
<!-- For strange and artistic reasons this
brand new release is code named the <bf/Daybreak/ release.  -->
<!-- In commemoration of recent news this brand new release is codenamed
the <bf/The Newer Generation/ release. -->
<!-- In commemoration of Linux kernel 2.2 release
this brand new release is codenamed the <bf/Daniella/ release. -->
<!--O
For unclear reasons this brand new release is codenamed
-->
<!-- the <bf/Sauchiehall/ release. -->
<!--O
the <bf/Taylor3/ release.
-->
理由はないしょですが、
この最新版を <bf/Taylor3/ 版と呼ぶことにしたいと思います。 

<!--O
New code names will appear as per industry standard guidelines
to emphasize the state-of-the-art-ness of this document.
-->
新たなコードネームは工業規格に則り、
この文書の現状を示すものです。

<p>
<!--O
This document was written for two reasons, mainly because I got hold
of 3 old SCSI disks to set up my Linux system on and I was pondering
how best to utilise the inherent possibilities of parallelizing in a
SCSI system. Secondly I hear there is a prize for people who write
documents...
-->
この文書を書いた理由は 2 つあります。
ひとつめは、私が 3 台の古い SCSIディスクを使って
Linux システムを立ちあげたとき、
どのように使うのがベストであるかを試行錯誤したためです。
もうひとつは、文書を書く人はごほうびがもらえると聞いたからです...

<!--O
This is intended to be read in conjunction with the Linux Filesystem
Structure Standard (FSSTND). It does not in any way replace it but tries to
suggest where physically to place directories detailed in the FSSTND,
in terms of drives, partitions, types, RAID, file system (fs),
physical sizes and other parameters that should be considered and
tuned in a Linux system, ranging from single home systems to large
servers on the Internet.
-->
この文書は Linux Filesystem Structure Standard (FSSTND) と
一緒に読んでもらうことを念頭において書きました。
もちろん FSSTND にとって変わろうとするものではありません。
FSSTND に現れるディレクトリを物理的にどう振り分けるかについての
提案をしようというものです。
ドライブ、パーティション、型式、RAID、
ファイルシステム、容量といったパラメータに関して考察し、
自宅で使うシステムから大規模なインターネットサーバに至る
各種の Linux システムにおいて、これらをどう扱い、
どう最適化するかについて述べます。

<!-- 
Even though it is now more than a year since last release of the FSSTND
work is still continuing, under a new name, and will encompass more than
Linux, fill in a few blanks hinted at in FSSTND version 1.2 as well as
other general improvements. The development mailing list is currently
private but a general release is hopefully in the near future.
-->

<!--O
The followup to FSSTND is called the Filesystem Hierarchy Standard (FHS)
and covers more than Linux alone. FHS versions 2.0 and 2.1 have been
released but there are still a few issues to be dealt with and even
longer before this new standard will have an impact on actual
distributions. FHS is not yet used in any distributions but Debian
has announced they will use it in Debian 2.1 which is the current
distribution. Also SuSE is aiming for FHS compliance and no doubt more
will come.
-->
FSSTND の次バージョンは Filesystem Hierarchy Standard という名前になり、
Linux 以外もカバーする予定です。
すでに FHS 2.0 と 2.1 がリリースされていますが、
まだやらなければならない部分が少々残っており、
この新しい標準が実際のディストリビューションに反映されるまでには
だいぶかかるでしょう。
FHS を用いたディストリビューションまだ存在しませんが、
Debian は現在のリリースである 2.1 で FHS を用いるとアナウンスしています。
SuSE も次の配布で FHS 準拠を目指しています。

<!--O
It is also a good idea to read the Linux Installation guides thoroughly
and if you are using a PC system, which I guess the majority still does,
you can find much relevant and useful information in the FAQs for the
newsgroup comp.sys.ibm.pc.hardware especially for storage media.
-->
Linux インストールガイドの類をよく読んでおくのも良い考えです。
PC のシステムを使っている方 (ほとんどでしょ？) は
comp.sys.ibm.pc.hardware ニュースグループの FAQ を読めば、
特に記憶メディアに関して有益な情報が得られるでしょう。

<!--O
This is also a learning experience for myself and I hope I can start
the ball rolling with this HOWTO and that it perhaps can evolve
into a larger more detailed and hopefully even more correct HOWTO.
-->
この文書を書くことは私自身の学習でもあります。
私はこの文書を、もっと内容が豊富でもっと正確なものに発展させたいと
考えています。

<!-- Removed 2303
Note that this is a guide on how to design and map logical partitions
onto multiple disks and tune for performance and reliability, NOT how
to actually partition the disks or format them - yet.
 -->

<!--O
First of all we need a bit of legalese. Recent development shows it is
quite important.
-->
まず最初に法的な面に関する記述を少々。
最近この文書も大きくなってきたので、
このような記述が必要になってきました。

<sect1>Copyright
<p>

This HOWTO is copyrighted 1996 Stein Gjoen.

Unless otherwise stated, Linux HOWTO documents are copyrighted by their
respective authors. Linux HOWTO documents may be reproduced and distributed
in whole or in part, in any medium physical or electronic, as long as
this copyright notice is retained on all copies. Commercial redistribution
is allowed and encouraged; however, the author would like to be notified of
any such distributions.

All translations, derivative works, or aggregate works incorporating
any Linux HOWTO documents must be covered under this copyright notice.
That is, you may not produce a derivative work from a HOWTO and impose
additional restrictions on its distribution. Exceptions to these rules
may be granted under certain conditions; please contact the Linux HOWTO
coordinator at the address given below.

In short, we wish to promote dissemination of this information through as
many channels as possible. However, we do wish to retain copyright on the
HOWTO documents, and would like to be notified of any plans to redistribute
the HOWTOs.

If you have questions, please contact
<!-- Greg Hankins, --> the Linux HOWTO coordinator,
at linux-howto@metalab.unc.edu via email.

日本語訳：

この文書の著作権は (C) 1996 Stein Gjoen が保有しています。

特に断りがない限り、 Linux HOWTO 文書の著作権は
それぞれの著者が保有しています。
Linux HOWTO 文書の全体あるいは一部は、物理的電子的を問わず、
あらゆるメディアに自由に複写できます。
ただしその際にはこの著作宣言をすべてのコピーに付加する必要があります。
商業的な配布も許可し、また奨励します。
しかしその際には著者にお知らせくださるようお願いします。

Linux HOWTO の文書を含んだ翻訳、修正および編集作業の成果は、
すべてこの著作権条項に従う必要があります。すなわちこの HOWTO を修正した後に、
配布条件に追加項を加えることはできません。
但し適当と認められた場合は例外とすることもできます。
Linux HOWTO の管理者に連絡してください。アドレスは以下に示します。

要するに我々はこれらの情報を可能な限りの方法で広めたいと思っているのです。
しかし我々は HOWTO 文書に関する著作権は保持し続けたいと望んでいます。
また、 HOWTO を再配布する計画については知らせてほしいと思っています。

もし疑問点があったら、Linux HOWTO の管理者に連絡してください。
電子メールのアドレスは <tt/linux-howto@metalab.unc.edu/ です。

<!--O
<sect1>Disclaimer
-->
<sect1>免責
<p>

Use the information in this document at your own risk. I disavow any
potential liability for the contents of this document. Use of the
concepts, examples, and/or other content of this document is entirely
at your own risk.

All copyrights are owned by their owners, unless specifically noted
otherwise.  Use of a term in this document should not be regarded as
affecting the validity of any trademark or service mark.

Naming of particular products or brands should not be seen as endorsements.

You are strongly recommended to take a backup of your system before
major installation and backups at regular intervals.

日本語訳：

この文書にある情報は、読者自身の責任の下に用いるようにしてください。
この文書中に存在するかもしれない誤りに関して、筆者は一切責任を持ちません。
この文書の概念や例、その他いかなる内容に関しても、
これを用いる際には読者が判断し、責任をとってください。

各著作権は特に記述がない限り、それぞれの保有者に帰するものとします。
この文書中における語句の引用は、
その商標の範囲には抵触しないものとみなされます。

インストール作業をする前にはシステムのバックアップをとっておくこと、
また定期的にバックアップをとり続けることを強く推奨します。

<!--O
<sect1>News
-->
<sect1>新着情報
<p>
<nidx>disk!news on</nidx>

<!--O
This is a maintenance release featuring minor but numerous updates
and additions to file systems and also tools for mount tables.
-->
これは管理用のリリースで、あまり重大ではないが数多くある更新と、
ファイルシステム・mount テーブル用のツールに対する追加とを行っています。

<!-- This release features a major restructuring and more additions
than I can list here especially on 
backup systems, hints and tips and even more on file system support.
Also there is now a new appendix with a shell script that helps
you characterise your system which is useful for debugging,
especially when asking others for help.
Also a section on troubleshooting has been added
as well as a subsection on mount options.

このリリースでは大規模な再構成を目的としています。
ここにはリストしきれなかった多くの情報も追加されました。
バックアップシステム、便利なワザ、
ファイルシステムのサポート状況に関してもさらに追加しています。
また新しい付録として、システムの状態を知る際に便利なシェルスクリプト
が追加されました。デバッグするとき、特に他の人に助けを求めるときに
重宝すると思います。またトラブルシュートの章と、
マウントのオプションに関する節も追加されました。

This HOWTO now uses indexing and is based on SGMLtools version 1.0.5
and the old version will therefore not format this document properly.

本 HOWTO では、今後 indexing を採用し、
SGMLtools の 1.0.5 版に基づいて記述します。
したがって古い版ではこの文書を正しく整形できないかもしれません。

Also quite new is a number of new translations available.
Now a Chinese and also an Italian translation are under way.

またこれも最近のことですが、
たくさんの翻訳版が新たに利用可能になりました。
現在中国語訳、イタリア語訳が進行中です。
 -->

<!--O
On the development front people are concentrating their energy towards
completing Linux 2.4 and until that is released there is not going to
be much news on disk technology for Linux.
-->
開発の最前線にいる人々は、 Linux 2.4 を完成させるために
エネルギーを集中しています。ですのでこれがリリースされるまでは
Linux のディスク技術には大きなニュースは現れないかもしれません。

<!-- Debian 2.1 is readying for release and as I use Debian for my test
systems I will make more updates when I upgrade. -->

<!--O
Also now the document is available in postscript
both for US letter as well as European A4 formats.
-->
この文書は PostScript でも入手できるようになりました。
アメリカの letter フォーマットとヨーロッパでの A4 フォーマット
の両方を用意しました。

<!--O
The latest version number of this document can be gleaned from my
plan entry if you <!-\- do "finger sgjoen@nox.nyx.net" -\->
<!-\- <url url="http://www.cs.indiana.edu/finger/nox.nyx.net/sgjoen" -\->
<url url="http://www.mit.edu:8001/finger?sgjoen@nox.nyx.net"
    name="finger"> my Nyx account.
-->
この文書の最新バージョンの番号は、私の Nyx のエントリを
<url url="http://www.mit.edu:8001/finger?sgjoen@nox.nyx.net"
    name="finger">
すれば、私の plan ファイルのエントリに表示されます。

<!--O
Also, the latest version will be available on my web space on Nyx
in a number of formats:
-->
またこの文書の最新バージョンは、
Nyx における私の Web ページでも閲覧できるようになりました。
各種フォーマットで置いてあります。
<itemize>
<item>
<url url="http://www.nyx.net/&tilde;sgjoen/disk.html"
    name="HTML">.

<item>
<!--O
<url url="http://www.nyx.net/&tilde;sgjoen/disk.txt"
    name="plain ASCII text"> (ca. 6200 lines).
-->
<url url="http://www.nyx.net/&tilde;sgjoen/disk.txt"
    name="プレイン ASCII テキスト"> (約 6200 行)

<item>
<!--O
<url url="http://www.nyx.net/&tilde;sgjoen/disk-US.ps.gz"
    name="compressed postscript US letter format"> (ca. 90 pages).
-->
<url url="http://www.nyx.net/&tilde;sgjoen/disk-US.ps.gz"
    name="圧縮した PostScript ファイル (US letter フォーマット)">
(約 90 ページ)

<item>
<!--O
<url url="http://www.nyx.net/&tilde;sgjoen/disk-A4.ps.gz"
    name="compressed postscript European A4 format"> (ca. 85 pages).
-->
<url url="http://www.nyx.net/&tilde;sgjoen/disk-US.ps.gz"
    name="圧縮した PostScript ファイル (ヨーロッパの A4 フォーマット)">
(約 85 ページ)

<item>
<!--O
<url url="http://www.nyx.net/&tilde;sgjoen/disk.sgml"
    name="SGML source"> (ca. 260 KB).
-->
<url url="http://www.nyx.net/&tilde;sgjoen/disk.sgml"
    name="SGML ソース"> (約 260 KB)

</itemize>


<!--O
A European mirror of the
<!-\- <url url="http://home.sol.no/&tilde;gjoen/stein/disk.html" -\->
<url url="http://home.online.no/&tilde;ggjoeen/stein/disk.html"
    name="Multi Disk HOWTO">
just went on line.
-->
ヨーロッパにおける
<url url="http://home.online.no/&tilde;ggjoen/stein/disk.html"
    name="Multi Disk HOWTO">
のミラーも登場しました。

<!--O
<sect1>Credits
-->
<sect1>謝辞
<p>
<!--O
In this version I have the pleasure of acknowledging even more people
who have contributed in one way or another:
-->
このバージョンでは、おかげでさらに多くの人々の貢献をいただくことができました。
ここに記して感謝します。
<!-- sjmudd (at) phoenix.ea4els.ampr.org changes to sjmudd (at) redestb.es -->

<tscreen><verb>
ronnej (at ) ucs.orst.edu
cm (at) kukuruz.ping.at
armbru (at) pond.sub.org
R.P.Blake (at) open.ac.uk
neuffer (at) goofy.zdv.Uni-Mainz.de
sjmudd (at) redestb.es
nat (at) nataa.fr.eu.org
sundbyk (at) oslo.geco-prakla.slb.com
ggjoeen (at) online.no
mike (at) i-Connect.Net
roth (at) uiuc.edu
phall (at) ilap.com
szaka (at) mirror.cc.u-szeged.hu
CMckeon (at) swcp.com
kris (at) koentopp.de
edick (at) idcomm.com
pot (at) fly.cnuce.cnr.it
earl (at) sbox.tu-graz.ac.at
ebacon (at) oanet.com
vax (at) linkdead.paranoia.com
tschenk (at) theoffice.net
pjfarley (at) dorsai.org
jean (at) stat.ubc.ca
johnf (at) whitsunday.net.au
clasen (at) unidui.uni-duisburg.de
eeslgw (at) ee.surrey.asc.uk
adam (at) onshore.com
anikolae (at) wega-fddi2.rz.uni-ulm.de
cjaeger (at) dwave.net
eperezte (at) c2i.net
yesteven (at) ms2.hinet.net
cj (at) samurajdata.se
tbotond (at) netx.hu
russel (at) coker.com.au
lars (at) iar.se
GALLAGS3 (at) labs.wyeth.com
morimoto (at) xantia.citroen.org
shulegaa (at) gatekeeper.txl.com
roman.legat (at) stud.uni-hannover.de
ahamish (at) hicks.alien.usr.com
hduff2 (at) worldnet.att.net
mbaehr (at) email.archlab.tuwien.ac.at
adc (at) postoffice.utas.edu.au
pjm (at) bofh.asn.au
jochen.berg (at) ac.com
jpotts (at) us.ibm.com
jarry (at) gmx.net
LeBlanc (at) mcc.ac.uk
</verb></tscreen>




<!--O
<sect1>Translations
-->
<sect1>翻訳
<p>

<!--O
Special thanks go to <tt/nakano (at) apm.seikei.ac.jp/ for doing the
<url url="http://www.linux.or.jp/JF/JFdocs/Multi-Disk-HOWTO.html"
    name="Japanese translation">, 
general contributions as well as contributing an example of
a computer in an academic setting, which is included at the end of this
document.
-->
<url url="http://www.linux.or.jp/JF/JFdocs/Multi-Disk-HOWTO.html"
    name="日本語訳">
やいろいろな貢献をしてくれた
<tt/nakano (at) apm.seikei.ac.jp/ には特に感謝します。
彼は大学で用いているコンピュータの設定についての例も送ってくれました。
この設定例は文書の最後に載っています。

<!--O
There are now many new translations available and special thanks go
to the translators for the job and the input they have given:
-->
いまや、たくさんの新たな翻訳版が入手できるようになりました。
翻訳者の皆さんの作業と、彼らからいただいた情報とに感謝します。

<itemize>
<!--O
<item><url url="http://www.linuxdoc.org/"
    name="German Translation"> by <tt/chewie (at) nuernberg.netsurf.de/
-->
<item><url url="http://www.linuxdoc.org/"
    name="ドイツ語訳"> by <tt/chewie (at) nuernberg.netsurf.de/

<!--O
<item><url url="http://www.swe-doc.linux.nu"
    name="Swedish Translation "> by <tt/jonah (at) swipnet.se/
-->
<item><url url="http://www.swe-doc.linux.nu"
    name="スウェーデン語訳"> by <tt/jonah (at) swipnet.se/

<!--O
<item><url url="http://www.lri.fr/&tilde;loisel/howto/"
    name="French Translation"> by <tt/Patrick.Loiseleur (at) lri.fr/
-->
<item><url url="http://www.lri.fr/&tilde;loisel/howto/"
    name="フランス語訳"> by <tt/Patrick.Loiseleur (at) lri.fr/

<!--O
<item><url url="http://www.linuxdoc.org/"
    name="Chinese Translation"> by <tt/yesteven (at ) ms2.hinet.net/
-->
<item><url url="http://www.linuxdoc.org/"
    name="中国語訳"> by <tt/yesteven (at ) ms2.hinet.net/

<!--O
<item><url url="http://www.pluto.linux.it/ildp/HOWTO/Multi-Disk-HOWTO.html"
    name="Italian Translation"> by <tt/bigpaul (at) flashnet.it/
-->
<item><url url="http://www.pluto.linux.it/ildp/HOWTO/Multi-Disk-HOWTO.html"
    name="イタリア語訳"> by <tt/bigpaul (at) flashnet.it/

</itemize>


<!--O
ICP Vortex is gratefully acknowledges for sending in-depth information
on their range of RAID controllers.
-->
ICP Vortex は、彼らの様々な RAID コントローラ
に関して詳細な情報を送ってくださいました。感謝します。

<!--O
Also DPT is acknowledged for sending me documentation on their controllers
as well as permission to quote from the material. These quotes have been
approved before appearing here and will be clearly labelled. No quotes as
of yet but that is coming.
-->
DPT にも感謝します。
彼らは自社のコントローラに関する文書を送って下さり、
またその文書からの引用を許可していただきました。
まだこの文書には掲載していませんが、すでに引用許可はいただいています。
掲載の際には引用部分がはっきりとわかるようにするつもりです。

<!--O
Not many still, so please read through this document, make a contribution
and join the elite. If I have forgotten anyone, please let me know.
-->
まだ多くはありません。
この文書を読んでこの文書に貢献し、是非エリートの仲間入りをしてください。
もし忘れている人がいましたら知らせてください。

訳注: 邦訳にあたっては JF メーリングリストの皆さん
(水原さん・松本さん・岡本さん・山下さん・大畑さん・高橋さん)
に有益なご意見をいただきました。
また長谷川さんと武井さんには校正をしていただき、
たくさんのご指摘をいただきました。
ありがとうございました。

<!--O
New in this version is an appendix with a few tables you can fill in
for your system in order to simplify the design process.
-->
この版では付録にいくつかの表を用意してあります。
この表を埋めていくことで、システムの設計が簡単になると思います。

<!--O
Any comments or suggestions can be mailed to my mail address on Nyx:
<htmlurl url="mailto:sgjoen@nyx.net/"
    name="sgjoen@nyx.net">.
-->
どんなことでも結構ですから、
ご意見がありましたら私の Nyx のメールアドレス
<htmlurl url="mailto:sgjoen@nyx.net" name="sgjoen@nyx.net">
までお送りください。


<!--O
So let's cut to the chase where <tt/swap/ and <tt>/tmp</tt> are
racing along hard drive...
-->
では、 <tt/swap/ と <tt>/tmp</tt> とが、
ハードディスク上でつばぜり合いをしているところを見ることにしましょう...

<p>

<!-- <hrule> -->

<!--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 -->

<!--O
<sect>Structure
-->
<sect>ディスクデバイスの論理構造とこの文書の構成
<p>
<!--O
As this type of document is supposed to be as much for learning
as a technical reference document I have rearranged the structure
to this end. For the designer of a system it is more useful to
have the information presented in terms of the goals of this exercise
than from the point of view of the logical layer structure of the
devices themselves. Nevertheless this document would not be complete
without such a layer structure the computer field is so full of, so
I will include it here as an introduction to how it works.
-->
この HOWTO のような文書は、
学習用だけでなく技術的な参考文書として用いられることも多いので、
文書の構成を変更しました。
システムの設計をする人にとっては、
デバイスの論理的な階層構造の面から記述するより、
この文書の本来の目的に沿って記述する方が有益であると考えました。
とはいえ、このような階層構造
(コンピュータの分野ではあちこちに出てきます)
を無視してはこの文書が成り立たないのも事実です。
そこで、この節ではまず階層構造の働きについて導入的な記述をしておきます。

<!--O
It is a long time since the <em/mini/ in mini-HOWTO could be defended
as proper but I am convinced that this document is as long as it needs
to be in order to make the right design decisions, and not longer.
-->
この文書はすでにかなりの大部になってしまいました。
しかし、この文書の内容はすべてシステム設計をするために必要なものであり、
文書がいたずらに冗長になったわけではないと筆者は信じています。

<!--O
<sect1>Logical structure
-->
<sect1>ディスクの論理的構造
<p>
<nidx>disk!structure, I/O subsystem</nidx>
<!--O
This is based on how each layer access each other, traditionally
with the application on top and the physical layer on the bottom.
It is quite useful to show the interrelationship between each of
the layers used in controlling drives.
-->
以下の図は、
それぞれの層がお互いにどのように結びついているかを示したものです。
伝統的にはアプリケーション層を最も上、物理層を最も下に書きます。
デバイスのコントロールに用いられる各層間の関係をここで図示しておきます。
<!--O
<tscreen><verb>
        ___________________________________________________________
        |__     File structure          ( /usr /tmp etc)        __|
        |__     File system             (ext2fs, vfat etc)      __|
        |__     Volume management       (AFS)                   __|
        |__     RAID, concatenation     (md)                    __|
        |__     Device driver           (SCSI, IDE etc)         __|
        |__     Controller              (chip, card)            __|
        |__     Connection              (cable, network)        __|
        |__     Drive                   (magnetic, optical etc) __|
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

</verb></tscreen>
-->
<verb>
	___________________________________________________________
	|__	ディレクトリ構造	( /usr /tmp など)	__|
	|__	ファイルシステム	(ext2fs, vfat など)	__|
	|__	ボリューム管理		(AFS)			__|
	|__	RAID・ディスク結合	(md)			__|
	|__	デバイスドライバ	(SCSI, IDE など)	__|
	|__	コントローラ		(chip, card)		__|
	|__	接続			(cable, network)	__|
	|__	ドライブ		(magnetic, optical など)__|
	-----------------------------------------------------------
</verb>

<!--O
In the above diagram both volume management and RAID and concatenation
are optional layers. The 3 lower layers are in hardware.
All parts are discussed at length later on in this document.
-->
上図のうち「ボリューム管理」および
「RAID・ディスク結合」の層は省略される場合もあります。
下の 3 層がハードウェアとみなされます。
この文書には、これらの各層すべてについて必要な情報が与えられています。

<!--O
<sect1>Document structure
-->
<sect1>文書の構成
<p>
<!--O
Most users start out with a given set of hardware and some plans on
what they wish to achieve and how big the system should be. This is
the point of view I will adopt in this document in presenting the
material, starting out with hardware, continuing with design constraints
before detailing the design strategy that I have found to work well.
I have used this both for my own personal computer at home, a multi
purpose server at work and found it worked quite well. In addition my
Japanese co-worker in this project have applied the same strategy on
a server in an academic setting with similar success.
-->
ほとんどのユーザは手元にあるハードウェアから作業を開始するでしょうが、
目的が先にあって、
システムをどの程度の大きさにするかを計画しているような人もいるでしょう。
どちらかというと後者を想定してこの文書は構成してあります。
まずハードウェアの話から始め、デザインに当たっての制限、
そして具体的なレイアウトの手法へと続きます。
ここで紹介している手法は私自身も用いており、
自宅の PC と仕事で使っている多目的サーバの両方で非常にうまく機能しています。
またこの文書プロジェクトに参加している日本のユーザも
同様の手法を大学で利用しているサーバに用い、同様に成功しています。

<!--O
Finally at the end I have detailed some configuration tables for use
in your own design. If you have any comments regarding this or notes
from your own design work I would like to hear from you so this
document can be upgraded.
-->
この文書の最後には私自身が用いた設定チャートを紹介しています。
こちらに関するコメントや、また皆さんがご自分の設計作業から得た情報を、
ぜひお聞きしたいと思っています。そのような例が集まれば、
この文書はさらに更新できるでしょう。
	
<!--O
<sect1>Reading plan
-->
<sect1>リーダースガイド
<p>
<!--O
Although not the biggest HOWTO it is nevertheless rather big already
and I have been requested to make a reading plan to make it possible
to cut down on the volume
-->
まだ最大の HOWTO になったわけではありませんが、
でもこの文書はだいぶ大きくなりました。
全体を読み通すのはしんどいので、
どの部分を読めば良いかを教えてほしい、
というリクエストをいただきましたので、以下に挙げてみます。

<descrip>
<!--O
<tag/Expert/ (aka the elite). If you are familiar with Linux as well
as disk drive technologies you will find most of what you need in the
appendices. Additionally you are recommended to read the FAQ and the
<ref id="bits-n-pieces" name="Bits'n'pieces">
chapter.
-->
<tag/エキスパート (エリート)/
Linux やディスクドライブの技術について良くご存じなら、
あなたがもっとも望んでいる情報はきっと付録にあるでしょう。
また FAQ と
<ref id="bits-n-pieces" name="補遺">
の章も読んでいただきたいと思います。

<!--O
<tag/Experienced/ (aka Competent). If you are familiar with computers
in general you can go straight to the chapters on
<ref id="technologies" name="technologies">
and continue from there on.
-->
<tag/経験者 (有能な人)/
コンピュータ一般に対する知識を持っている人は、
<ref id="technologies" name="最新技術">
の章に飛んで、以降を読み進めてください。

<!--O
<tag/Newbie/ (mostly harmless). You just have to read the whole thing.
Sorry. In addition you are also recommended to read all the other disk
related HOWTOs.
-->
<tag/初心者 (タコ)/
全部読む必要があると思います、ごめんなさい。
また、他のディスク関連の HOWTO も読むことをお勧めします。
</descrip>

<!--O
<sect>Drive Technologies
-->
<sect>ドライブの技術
<p>
<nidx>disk!technologies</nidx>
<!--O
A far more complete discussion on drive technologies for IBM PCs
can be found at the home page of
<url url="http://thef-nym.sci.kun.nl/&tilde;pieterh/storage.html"
    name="The Enhanced IDE/Fast-ATA FAQ">
which is also regularly posted on Usenet News.
There is also a site dedicated to
<url url="http://ata-atapi.com"
    name="ATA and ATAPI Information and Software">.
-->
IBM PC のドライブの技術に関しては、この文書よりもずっと充実した議論が
<url url="http://thef-nym.sci.kun.nl/&tilde;pieterh/storage.html"
    name="The Enhanced IDE/Fast-ATA FAQ">
の Web ページにあります。
これは Usenet ニュースにも定期的にポストされています。
また ATA と ATAPI の情報やソフトウェアを集めたサイト
<url url="http://ata-atapi.com">
もあります。 

<!--O
Here I will just present what is needed to get an understanding
of the technology and get you started on your setup.
-->
ここではセットアップの際に必要となるドライブ関連技術の知識を
かいつまんで示します。

<!--O
<sect1>Drives
-->
<sect1>ドライブ
<p>
<nidx>disk!drives</nidx>
<!--O
This is the physical device where your data lives and although the
operating system makes the various types seem rather similar they
can in actual fact be very different. An understanding of how it
works can be very useful in your design work. Floppy drives fall
outside the scope of this document, though should there be a big
demand I could perhaps be persuaded to add a little here.
-->
ドライブとはデータを保持する物理デバイスのことです。
とてもたくさんの種類があり、
オペレーティングシステムからはどれも似たように見えますが、
中身は非常に異なっています。
それぞれがどのように機能しているかを知ることは、
後で行なうディスク配置の際に大きな助けとなるでしょう。
フロッピードライブに関しては今のところ無視していますが、
もし要望が多ければ将来追加するかもしれません。

<!--O
<sect1>Geometry
-->
<sect1>ジオメトリ
<p>
<nidx>disk!geometry</nidx>
<!--O
Physically disk drives consists of one or more platters containing
data that is read in and out using sensors mounted on movable heads
that are fixed with respects to themselves. Data transfers therefore
happens across all surfaces simultaneously which defines a cylinder
of tracks. The drive is also divided into sectors containing a
number of data fields.
-->
ディスクドライブは 1〜数枚の円板 (platter) からなっており、
ここにデータが読み書きされます。
読み書きを行なうのは移動式のヘッドに固定されたセンサーです。
それぞれの円板に対応する「ヘッド」はひとつのアームに固定されていて、
すべてのヘッドが一緒に動きます。
従ってデータ転送は全部の円板の表面から同時にされることになり、
これがトラックの「シリンダ」となります。
またドライブは「セクタ」によっても分割されています。
セクタは多数のデータフィールドから構成されています。

<!--O
Drives are therefore often specified in terms of its geometry: the
number of Cylinders, Heads and Sectors (CHS).
-->
これらシリンダ (Cylinder)、ヘッド (Head)、セクタ (Sector) の数 (以下
CHS と呼びます) のことをまとめて「ジオメトリ」と言います。
ドライブはこのジオメトリによって分類されます。

<!--O
For various reasons there is now a number of translations between
<itemize>
<item>the physical CHS of the drive itself
<item>the logical CHS the drive reports to the BIOS or OS
<item>the logical CHS used by the OS
</itemize>
-->
色々な理由から、今では以下のようなものの間で
CHS データの変換がされるようになっています。
<itemize>
<item>ドライブそのものの物理 CHS。
<item>ドライブが BIOS や OS に伝える論理 CHS
<item>OS によって用いられる論理 CHS
</itemize>

<!--O
Basically it is a mess and a source of much confusion. For more
information you are strongly recommended to read the
<em>Large Disk mini-HOWTO</em>
-->
このようになってしまっているのは、
つまるところシステムの出来が悪いためで、
様々な混乱の原因となっています。もっと知りたい方には
<em/Large Disk mini-HOWTO/ を推薦しておきます。

訳注:
<url url="http://www.linux.or.jp/JF/JFdocs/Large-Disk-HOWTO.html"
	name="Large Disk HOWTO の日本語訳">
は JF にあります。

<!--O
<sect1>Media
-->
<sect1>メディア
<p>
<nidx>disk!media</nidx>
<!--O
The media technology determines important parameters such as
read/write rates, seek times, storage size as well as if it is
read/write or read only.
-->
メディアの技術は、
ディスクの読み書き速度・シーク時間・記憶容量・
書き込み可能かリードオンリーとなるかなどの
重要な要素を決定づけます。

<!--O
<sect2>Magnetic Drives <label id="magnetic-drives">
-->
<sect2>磁気ディスク<label id="magnetic-drives">
<p>
<nidx>disk!media!magnetic</nidx>
<!--O
This is the typical read-write mass storage medium, and as
everything else in the computer world, comes in many flavours
with different properties. Usually this is the fastest technology
and offers read/write capability. The platter rotates with a
constant angular velocity (CAV) with a variable physical sector
density for more efficient magnetic media area utilisation.
In other words, the number of bits per unit length is kept
roughly constant by increasing the number of logical sectors
for the outer tracks.
-->
読み書き可能な大容量記憶媒体として代表的なものです。
コンピュータ分野の通例にもれず、
様々な特性、機能のものが乱立しています。
読み書き可能な通常のメディアの中では最速のものと言って良いでしょう。
ディスクは一定の角速度で回転しています。
磁気媒体の面積を有効に利用できるように、
物理セクタの線密度はディスクの内側と外側で異なっています。
長さ当たりのビット数がだいたい一定になるように、
外側のトラックでの論理セクタの数を増やしてあるのです。

<!--O
Typical values for rotational speeds are 4500 and 5400 RPM, though
7200 is also used. Very recently also 10000 RPM has entered
the mass market.
Seek times are around 10 ms, transfer rates quite variable from
one type to another but typically 4-40 MB/s.
With the extreme high performance drives you should remember that
performance costs more electric power which is dissipated as heat,
see the point on
<ref id="power-heating" name="Power and Heating">.
-->
回転角速度は通常 4500 か 5400 RPM
(rounds per minute: 一分間あたりの回転数) です。
7200 RPM のものも出まわっています。
ごく最近では 10000 RPM の製品も市場に出はじめているようです。
シーク時間は 10 ms 程度です。
転送速度はモデルによってだいぶ違いがありますが、
通常およそ 4〜40 MB/s 程度です。
高い性能を持ったドライブでは、
電力が余計に必要になることも忘れないでください。
この電力は最終的には熱に転化します。この点については
<ref id="power-heating" name="電力と発熱">
の節を参照してください。

<!--O
Note that there are several kinds of transfers going on here, and
that these are quoted in different units. First of all there is
the platter-to-drive cache transfer, usually quoted in
Mbits/s. Typical values here is about 50-250 Mbits/s. The second
stage is from the built in drive cache to the adapter, and this
is typically quoted in MB/s, and typical quoted values here is
3-40 MB/s. Note, however, that this assumed data is already in
the cache and hence for maximum readout speed from the drive the
effective transfer rate will decrease dramatically.
-->
データの転送にはいくつかの段階があり、
それぞれ異なった単位が用いられることに注意してください。
まず磁気円板からドライブ内のキャッシュまでの転送があり、
これは通常 Mbits/s で表されます。
一般的には 50〜250 Mbits/s 程度のものが多いようです。
次にドライブ内に組み込まれたキャッシュからホストアダプタまでの転送があります。
これは MB/s で記述され、
3〜40 MB/s 程度であることが多いようです。
ただしこれはキャッシュの中にデータが存在している場合の
最高速度を表したものであり、実際の転送速度はもっとずっと低くなります。

<!-- removed due to redundancy with the above lines
<p>
Drives are usually described by the geometry or drive parameters which
is the number of heads, sectors and cylinders, which is confused by
translation schemes between physical and various logical geometries.
This is a mine field which is described in painful details in many
storage related FAQs. Read and weep.
 -->

<!--O
<sect2>Optical Drives
-->
<sect2>光ディスク
<p>
<nidx>disk!media!optical</nidx>
<!--O
Optical read/write drives exist but are slow and not so common. They
were used in the NeXT machine but the low speed was a source for much
of the complaints. The low speed is mainly due to the thermal nature
of the phase change that represents the data storage. Even when using
relatively powerful lasers to induce the phase changes the effects are
still slower than the magnetic effect used in magnetic drives.
-->
光を利用した読み書き可能なディスクも存在していますが、
遅いのでそれほど一般的ではありません。
NeXT のマシンで用いられているようですが、
遅いせいで良く文句のタネになっています。
データの保存には相変化を用いますが、
このときの熱特性が書き込み速度を決めています。
たとえ強力なレーザを用いたとしても、
相変化を引き起こす温度変化にかかる時間は
磁気ドライブの磁気効果の時間よりも遅いのです。

<!--O
Today many people use CD-ROM drives which, as the
name suggests, is read-only. Storage is about 650 MB, transfer speeds
are variable, depending on the drive but can exceed 1.5 MB/s. Data is
stored on a spiraling single track so it is not useful to talk about
geometry for this. Data density is constant so the drive uses constant
linear velocity (CLV). Seek is also slower, about 100 ms, partially due
to the spiraling track. Recent, high speed drives, use a mix of
CLV and CAV in order to maximize performance. This also reduces access
time caused by the need to reach correct rotational speed for readout.
-->
今日では多くの人々が CD-ROM を利用するようになっています。
名前からわかるようにこれはリードオンリーです。
容量はおよそ 650 MB、転送速度はドライブによりますが
1.5 MB/s 以上のものもあるようです。
データは渦巻状の一本のトラックに保存されます。
したがってジオメトリは意味を持ちません。
データ密度はトラック上で一定で、
ドライブは線速度が一定になるように回転します。
トラックが渦巻であるためにシーク動作も低速で、
大体 100 ミリ秒程度です。
最近では線速度一定動作と角速度一定動作を組み合わせて
性能を最適化させるようにもなってきています。
これによりシーク時の回転速度合わせの動作が軽減されるため、
アクセス時間も短縮できます。

<!--O
A new type (DVD) is on the horizon, offering up to about 18 GB on a
single disk.
-->
新型の光ディスク (DVD) も姿を現しつつあります。
これは一枚のディスクに 18 GB の容量を記録できます。

<!--O
<sect2>Solid State Drives
-->
<sect2>固体素子ディスク
<p>
<nidx>disk!media!solid state</nidx>
<!--O
This is a relatively recent addition to the available technology and
has been made popular especially in portable computers as well as in
embedded systems. Containing no movable parts they are very fast
both in terms of access and transfer rates. The most popular type is
flash RAM, but also other types of RAM is used. A few years ago many
had great hopes for magnetic bubble memories but it turned out to be
relatively expensive and is not that common.
-->
比較的最近利用されるようになった技術で、
ポータブルコンピュータや組み込みシステムではポピュラーになってきています。
動作部分が無いのでアクセスも転送も非常に高速です。
フラッシュ RAM が最も良く用いられていますが、他の形式もあります。
数年前には磁気バブルメモリが嘱望されたこともありましたが、
高価なので一般的にはなりませんでした。

<!--O
In general the use of RAM disks are regarded as a bad idea as it is
normally more sensible to add more RAM to the motherboard and let the
operating system divide the memory pool into buffers, cache, program
and data areas. Only in very special cases, such as real time systems
with short time margins, can RAM disks be a sensible solution.
-->
ところで RAM ディスクを用いるのは一般に良くないとされています。
RAM ディスクにするメモリがあるなら、その分を OS に管理させ、
バッファやキャッシュ、プログラム領域、
データ領域などとして利用する方が有効だからです。
RAM ディスクが有効なのは非常に特殊な場合、
例えばタイムマージンの厳しい
リアルタイムシステムなどだけであると考えてください。

<!--O
Flash RAM is today available in several 10's of megabytes
in storage and one might be tempted to use it for fast, temporary
storage in a computer. There is however a huge snag with this: flash
RAM has a finite life time in terms of the number of times you can
rewrite data, so putting 
<tt>swap</tt>, <tt>/tmp</tt> or <tt>/var/tmp</tt> on such
a device will certainly shorten its lifetime dramatically.
Instead, using flash RAM for directories that are read often but
rarely written to, will be a big performance win.
-->
今日では数 10 MB サイズのフラッシュ RAM が利用できるようになりましたので、
これを高速な一時記憶領域として利用したくなるかもしれません。
しかしこれには大きな問題があります。フラッシュ RAM には寿命があって、
再書き込みを行える回数に制限があるのです。
したがってこのようなデバイスをスワップや <tt>/tmp</tt>,
<tt>/var/tmp</tt> などにあてがうと、
これらの寿命を非常に縮めることになってしまいます。
そのかわりに、フラッシュ RAM を
「頻繁に読み込まれるがめったに書き込まれないディレクトリ」に用いると、
非常に性能が向上するでしょう。

<!--O
In order to get the optimum life time out of flash RAM you will
need to use special drivers that will use the RAM evenly and
minimize the number of block erases.
-->
フラッシュ RAM の寿命をより長くしたい場合は、
専用のドライバを用いて RAM の全領域を均等に用いたり、
ブロック消去の回数を減らしたりする必要があるでしょう。

<!--O
This example illustrates the advantages of splitting up your directory
structure over several devices.
-->
これは「ディレクトリごとに割り当てるデバイスを変える」
ことによる利点を示す例であると言えます。

<!--O
Solid state drives have no real cylinder/head/sector addressing but for
compatibility reasons this is simulated by the driver to give a uniform
interface to the operating system.
-->
固体素子のディスクは実体としての CHS アドレスを持っていません。
しかし OS とのインターフェースを共通にするために、
ドライバが見せかけの CHS アドレスを割り当てるようになっています。

<!--O
<sect1>Interfaces
-->
<sect1>インターフェース
<p>
<nidx>disk!interfaces</nidx>
<!--O
There is a plethora of interfaces to chose from widely ranging in
price and performance. Most motherboards today include IDE interface
which are part of modern chipsets.
-->
世の中には選ぶのに困ってしまうほど多種多様のインターフェースがあり、
価格や性能も様々です。最近のほとんどのマザーボードには、
新世代のチップセットの一部として IDE のインターフェースが付属しています。

<!--O
Many motherboards also include a SCSI interface chip made by Symbios
(formerly NCR) and that is connected directly to the PCI bus.  Check
what you have and what BIOS support you have with it.
-->
SCSI インターフェース機能を持っているマザーボードも多くなりました。
これらは Symbios (以前の NCR) のチップを直接 PCI バスに接続しています。
お使いのマザーボードの機能と BIOS サポートを調べておくと良いでしょう。

<!--O
<sect2>MFM and RLL
-->
<sect2>MFM と RLL
<p>
<nidx>disk!interfaces!MFM</nidx>
<nidx>disk!interfaces!RLL</nidx>
<!--O
Once upon a time this was the established technology, a time when
20 MB was awesome, which compared to todays sizes makes you think
that dinosaurs roamed the Earth with these drives. Like the dinosaurs
these are outdated and are slow and unreliable compared to what we
have today. Linux does support this but you are well advised to
think twice about what you would put on this. One might argue that
an emergency partition with a suitable vintage of DOS might be
fitting.
-->
むかしむかし、まだ 20 MB のハードディスクが羨望の目で眺められていた頃には、
これらは最先端の技術でした。今日の容量と比べると、
まるで恐竜がいた頃なんじゃないかとさえ思えますね。
これらの技術も恐竜同様すでに滅んでしまいました。
今日のものに比べると速度でも信頼性でも劣るからです。 
Linux は MFM や RLL をサポートしていますが、
これらのインターフェースにドライブを繋ぐのは全くお勧めできません。
それでも強いて繋ぐなら、同じく過去の遺物である DOS を入れて、
緊急用のパーティションにしておくのがせいぜいでしょう。

<sect2>ESDI
<p>
<nidx>disk!interfaces!ESDI</nidx>
<!--
This technology became outdated almost before it got popular, so you
are unlikely to come across it these days. Basically it was an attempt
of increasing the upper limit of the old interfaces. You might get
such a drive to work under Linux if it is compatible with the <tt/ST506/
standard. -->
<!-- Update from edick 970912 -->
<!--O
Actually, ESDI was an adaptation of the very widely used SMD interface used on
"big" computers to the cable set used with the ST506 interface, which was more
convenient to package than the 60-pin + 26-pin connector pair used with SMD. 
The ST506 was a "dumb" interface which relied entirely on the controller and
host computer to do everything from computing head/cylinder/sector locations
and keeping track of the head location, etc. ST506 required the controller to
extract clock from the recovered data, and control the physical location of
detailed track features on the medium, bit by bit. It had about a 10-year life
if you include the use of MFM, RLL, and ERLL/ARLL modulation schemes. ESDI,
on the other hand, had intelligence, often using three or four separate
microprocessors on a single drive, and high-level commands to format a track,
transfer data, perform seeks, and so on. Clock recovery from the data stream
was accomplished at the drive, which drove the clock line and presented its
data in NRZ, though error correction was still the task of the controller. 
ESDI allowed the use of variable bit density recording, or, for that matter,
any other modulation technique, since it was locally generated and resolved at
the drive. Though many of the techniques used in ESDI were later incorporated
in IDE, it was the increased popularity of SCSI which led to the demise of ESDI
in computers. ESDI had a life of about 10 years, though mostly in servers and
otherwise "big" systems rather than PC's.
-->
ESDI は SMD に合わせて作られた技術でした。
SMD インターフェースは
「巨大な」コンピュータで広く使われたインターフェースですが、これを
ST506 インターフェースで用いられていたケーブルセットに合わせるためのものが
ESDI だったのです。
SMD で使われていた 60 ピン + 26 ピンのコネクタをペアで用意するより、
両者をまとめた ST506 のセットのほうが便利だったのでした。
ST506 は「間抜け」なインターフェースで、
コントローラとホストコンピュータにいろいろな作業をすべて任せていました
(CHS の場所の計算、ヘッド位置の追跡などなど)。
ST506 にはコントローラが必要で、
これはリカバーされたデータからクロックを取り出したり、
メディア上でのトラック構造の物理的な位置を
1 ビットずつ制御したりするものでした。
MFM や RLL, ERLL/ARLL モジュレーション機構などを含めることにすれば、
ST506 はおよそ 10 年ほどの寿命を保ちました。
一方 ESDI はインテリジェントなインターフェースで、
1 ドライブあたり 3〜4 つものマイクロプロセッサを使うのが普通でした。
トラックのフォーマット、データ転送、シーク動作などの
高レベルのコマンドが使えました。
データストリームからのクロックリカバリや、
クロックラインのドライブと NRZ へのデータ表示もドライブ側でできました。
ただしエラー修正はコントローラの受け持ちでした。
ESDI では可変長ビット密度での記録も可能でした、
というか他にもいろいろなデータ変調技術が使えました。
データはドライブでローカルに生成・分解できたからです。
ESDI の技術は、その多くが後に IDE に取り込まれましたが、
SCSI がポピュラーになるにつれ、
コンピュータでは利用されないようになっていきました。
ESDI は 10 年の寿命を保ったと書きましたが、
それは PC でのことではなく、
サーバなど「巨大な」システムでのことでした。


<!--O
<sect2>IDE and ATA
-->
<sect2>IDE と ATA
<p>
<nidx>disk!interfaces!IDE</nidx>
<nidx>disk!interfaces!ATA</nidx>
<!--O
Progress made the drive electronics migrate from the ISA slot
card over to the drive itself and Integrated Drive Electronics
was borne. It was simple, cheap and reasonably fast so the BIOS
designers provided the kind of snag that the computer industry is
so full of. A combination of an IDE limitation of 16 heads
together with the BIOS limitation of 1024 cylinders gave us the
infamous 504 MB limit. Following the computer industry traditions
again, the snag was patched with a kludge and we got all sorts of
translation schemes and BIOS bodges. This means that you need to
read the installation documentation very carefully and check up
on what BIOS you have and what date it has as the BIOS has to
tell Linux what size drive you have. Fortunately with Linux you
can also tell the kernel directly what size drive you have with
the drive parameters, check the documentation for LILO and Loadlin,
thoroughly. Note also that IDE is equivalent to ATA, AT Attachment.
IDE uses CPU-intensive Programmed Input/Output (PIO) to transfer
data to and from the drives and has no capability for the more
efficient Direct Memory Access (DMA) technology. Highest transfer
rate is 8.3 MB/s.
-->
その後の技術の進歩によって、
ドライブを制御する回路は ISA スロットからドライブ本体に置かれるようになり、
IDE (Integrated Drive Electronics) が誕生しました。
IDE は単純かつ安価で、またそれなりの速度を持っていたため、
多くの BIOS 設計者がこの技術を用いました。その結果
(コンピュータ業界には良くあることですが) 面倒な問題が起こりました。
ヘッド数が 16 までという IDE の制限と、シリンダ数が 1024 までという BIOS 
の制限が重ね合わさって、悪名高き 504 MB の制限が生れたのです。
さらにコンピュータ業界の伝統に習い、
この問題の解決にはその場しのぎのお粗末な方法が選択されました。
その結果全く互換性のない数多くの変換方法、
様々な仕様の BIOS が乱立しました。
この結果 Linux で BIOS
からドライブ容量の情報を取得するのが非常に面倒になりました。
インストール文書を隅から隅まで丁寧に読み、
使っている BIOS の種類とバージョンを調べなければならなくなったのです。
しかし幸いなことに Linux では BIOS を経由せずに
直接カーネルにドライブのパラメータ (従って容量も) を渡すこともできます。 
LILO と Loadlin のドキュメントを良く調べてみてください。
IDE と ATA  (AT Attachment) とは同じものです。 IDE でのデータ転送は
CPU 主導型の Programmed I/O  (PIO) です。
より効率的な Direct Memory Access  (DMA) 技術は使われていません。
転送速度の上限は 8.3 MB/s です。

<sect2>EIDE, Fast-ATA and ATA-2
<p>
<nidx>disk!interfaces!EIDE</nidx>
<nidx>disk!interfaces!Fast-ATA</nidx>
<nidx>disk!interfaces!ATA-2</nidx>
<!--O
These 3 terms are roughly equivalent, fast-ATA is ATA-2 but EIDE
additionally includes ATAPI. ATA-2 is what most use these days
which is faster and with DMA. Highest transfer rate is increased
to 16.6 MB/s.
-->
この 3 つは大体同じものです。 Fast-ATA と ATA-2 は同じもので、
EIDE はこれにさらに ATAPI を加えたものです。
ATA-2 は今日非常に広く用いられており、
IDE より高速で DMA も使っています。
転送速度は 16.6 MB/s に増加しています。

<!-- from c't 9/97 -->

<sect2>Ultra-ATA
<p>
<nidx>disk!interfaces!Ultra-ATA</nidx>
<!--O
A new, faster DMA mode that is approximately twice the speed of EIDE PIO-Mode 4
(33 MB/s). Disks with and without Ultra-ATA can be mixed on the same cable
without speed penalty for the faster adapters. The Ultra-ATA interface is
electrically identical with the normal Fast-ATA interface, including the
maximum cable length.
-->
より高速な新しい DMA モードで、
EIDE PIO-Mode 4 のおよそ２倍の速度 (33 MB/s) です。
Ultra-ATA モードを持つディスクと持たないディスクは同じケーブルで共存でき、
それによって高速な方のドライブのスピードが低下することもありません。
Ultra-ATA インターフェースは電気的にはノーマルの
Fast-ATA インターフェースと等価で、ケーブルの最大長も同じです。

<!--O
The newest development is the 66 MB/s version, DMA/66.
-->
最新の製品は 66 MB/s 版の DMA/66 です。

<sect2>ATAPI
<p>
<nidx>disk!interfaces!ATAPI</nidx>
<!--O
The ATA Packet Interface was designed to support CD-ROM drives
using the IDE port and like IDE it is cheap and simple.
-->
ATA パケットインターフェースは
IDE のポートで CD-ROM ドライブを利用するために設計されました。
IDE と同様、ATAPI は安価でシンプルです。

<sect2>SCSI
<p>
<nidx>disk!interfaces!SCSI</nidx>
<!--O
The Small Computer System Interface is a multi purpose interface
that can be used to connect to everything from drives, disk arrays,
printers, scanners and more. The name is a bit of a misnomer as it
has traditionally been used by the higher end of the market as well
as in work stations since it is well suited for multi tasking
environments.
-->
SCSI  (Small Computer System Interface)  は、
ドライブだけでなくディスクアレイやプリンタ、スキャナなど、
色々なものを繋げる多目的インターフェースです。
SCSI はマルチタスク環境に適しているため、
ワークステーションなどのハイエンド機に用いられてきました
(したがって &dquot;Small&dquot; というのは正確ではないかもしれません)。

<!--O
The standard interface is 8 bits wide and can address 8 devices.
There is a wide version with 16 bit that is twice as fast on the
same clock and can address 16 devices. The host adapter always
counts as a device and is usually number 7.
It is also possible to have 32 bit wide busses but this usually
requires a double set of cables to carry all the lines.
-->
SCSI のバンド幅は標準で 8 ビットで、 8 つのデバイスを接続できます。 
wide SCSI と呼ばれる規格ではバンド幅は 16 ビット
(したがって転送クロックが同じなら転送量は 2 倍)、
接続可能なデバイスは 16 個となっています。
ホストアダプタもひとつのデバイスとみなされます。
普通は 7 番がホストアダプタの ID に割り当てられます。
32 ビットの wide バスを使うこともできますが、
この場合すべての信号線を接続するには、
通常ケーブルが 2 セット必要になります。

<!--O
The old standard was 5 MB/s and the newer fast-SCSI increased this
to 10 MB/s. Recently ultra-SCSI, also known as Fast-20, arrived
with 20 MB/s transfer rates for an 8 bit wide bus.
New low voltage differential (LVD) signalling allows
these high speeds as well as much longer cabling than before.
-->
古い標準の規格では転送速度は 5 MB/s でしたが、新しい fast-SCSI では 
10 MB/s に増えています。最近では ultra-SCSI  (Fast-20 とも呼ばれます)
という規格が定まり、 8 ビット幅のバスで
20 MB/s の転送量を持つようになりました。
最新の、低電圧差動信号 (Low Voltage Differntial signal: LVD signal)
を用いる方式では、同程度の高い速度に加え、
以前よりずっと長いケーブルを使うことができます。

<!--O
Even more recently an even faster standard has been introduced:
SCSI 160 (originally named SCSI 160/m) which is capable of a monstrous 160 MB/s
over a 16 bit wide bus. Support is scarce yet but for a few
10000 RPM drives that can transfer 40 MB/s sustained.
Putting 6 such drives on a RAID will keep such a bus saturated
and also saturate most PCI busses. Obviously this is only for
the very highest end servers per today. More information on
this standard is available at
<url url="http://www.ultra160-scsi.com/"
    name="The Ultra 160 SCSI home page">
-->
さらに最近には、もっと速い規格も導入されています。
SCSI 160 (もとの名前は SCSI 160/m) で、 16 ビット幅のバスを用い、
なんと 160 MB/s の能力を持っています。
実装はまだまだですが、
10000 RPMディスクの中には 40 MB/s の転送を定常的に行えるものもあります。
このようなディスクを 6 台集めて RAID にすれば、
こんなバスも飽和 (そして PCI バスも飽和) させてしまうことができます。
現段階では、明らかに最高級のハイエンドサーバ用のものです。
この規格に関するより詳しい情報は
<url url="http://www.ultra160-scsi.com/"
    name="The Ultra 160 SCSI home page">
から入手できます。

<!--O
Adaptec just announced a Linux driver for their SCSI 160 host adapter.
More information will come when more information becomes available.
-->
最近 Adaptec は、彼らの 160 ホストアダプタ用の Linux ドライバの
発表をしました。詳しいことがわかりしだい、ここでもお知らせします。

<!--O
The higher performance comes at a cost that is usually higher than for
(E)IDE. The importance of correct termination and good quality cables
cannot be overemphasized. SCSI drives also often tend to be of a higher
quality than IDE drives. Also adding SCSI devices tend to be easier
than adding more IDE drives: Often it is only a matter of plugging
or unplugging the device; some people do this without powering down
the system. This feature is most convenient when you have multiple
systems and you can just take the devices from one system to the
other should one of them fail for some reason.
-->
通常 SCSI は (E)IDE よりも高性能ですが、価格も高い場合が多いようです。
ドライブも SCSI の方が IDE より性能が高い場合が多いです。
一方デバイスを追加するのは SCSI の方が簡単で、
ほとんどの場合は単にデバイスを抜き差しするだけです
(中には電源を入れたままでこれをやる人もいます)。
これは複数のシステムを持っている場合には非常に便利で、
どれかのシステムが何らかの理由で故障しても、
デバイスを移すだけですみます。

<!--O
There is a number of useful documents you should read if you use
SCSI, the SCSI HOWTO as well as the SCSI FAQ posted on Usenet News.
-->
SCSI に関してはためになる文書がたくさん出ています。 SCSI HOWTO や
SCSI FAQ などは、 Usenet ニュースにもポストされています。

<!--O
SCSI also has the advantage you can connect it easily to tape drives
for backing up your data, as well as some printers and scanners. It
is even possible to use it as a very fast network between computers
while simultaneously share SCSI devices on the same bus. Work is under
way but due to problems with ensuring cache coherency between the
different computers connected, this is a non trivial task.
-->
SCSI にはバックアップのためのテープドライブや、
一部のプリンタやスキャナを接続できるという利点もあります。
また別々のコンピュータを一つの SCSI バスに繋ぎ、
デバイスを共有させることで、超高速のネットワークを作ることさえ可能です。
作業は進行中のようですが、
接続された別々のコンピュータの間でキャッシュの整合性を保証するのが難しく、
それほど簡単な仕事ではないようです。

<!--O
SCSI numbers are also used for arbitration. If several drives request
service, the drive with the lowest number is given priority.
-->
SCSI 番号は調停 (arbitration) にも使われます。
複数のドライブが要求を同時に出した場合、
もっとも低い番号のドライブが優先されます。

<!--O
Note that newer SCSI cards will simultaneously support an array
of different types of SCSI devices all at individually optimized
speeds.
-->
新しい SCSI カードには、タイプの異なる複数の SCSI デバイスを、
それぞれ最適な速度で同時に使えるようなものもあります。


<!--O
<sect1>Cabling
-->
<sect1>配線
<p>
<nidx>disk!cabling</nidx>
<!--O
I do not intend to make too many comments on hardware but I feel I
should make a little note on cabling. This might seem like a
remarkably low technological piece of equipment, yet sadly it is the
source of many frustrating problems. At todays high speeds one should
think of the cable more of a an RF device with its inherent demands on
impedance matching. If you do not take your precautions you will get a
much reduced reliability or total failure. Some SCSI host adapters are
more sensitive to this than others.
-->
ハードウェア寄りの話をするつもりはあまりなかったのですが、
配線に関しては少々触れておく必要があるように感じました。
特に技術的に難しい部分ではないのですが、
ここがいろいろな問題の原因になっていることが多いのです。
今日のように高速な転送が行われるようになると、
ケーブルは高周波デバイスとして考える必要があり、
インピーダンスマッチングが重要になります。
しかるべき措置を行っておかないと信頼性は非常に低下しますし、
まったく動かなくなることもありえます。
SCSI ホストアダプタの一部の製品は、この点に非常に敏感です。

<!--O
Shielded cables are of course better than unshielded but the price is
much higher. With a little care you can get good performance from a
cheap unshielded cable.
-->
シールドケーブルはシールドされていないケーブルより良いに決まっていますが、
価格もとても高価になります。少々注意を払えば、
安価なシールドのないケーブルでも充分な性能が得られます。

<itemize>
<!-- from c't 9/97 -->
<!--O
<item>For Fast-ATA and Ultra-ATA, the maximum cable length is specified
as 45cm (18"). The data lines of both IDE channels are connected on many
boards, though, so they count as <bf/one/ cable. In any case EIDE cables
should be as short as possible. If there are mysterious crashes or 
spontaneous changes of data, it is well worth investigating your cabling. 
Try a lower PIO mode or disconnect the second channel and see if the problem
still occurs.
-->
<item>Fast-ATA と Ultra-ATA では、
ケーブルの最大長は 45 cm (18インチ) と決められています。
二つの IDE チャンネルのデータ線が結線されているようなマザーボードも多く、
これらでは 2 つのチャンネルが <bf/一本の/ ケーブルとして扱われます。
いずれにしても、 EIDE のケーブルはできる限り短くすべきです。
原因不明のクラッシュや間欠的なデータ破壊などが生じた場合には、
ケーブルを調べて見る価値はあるでしょう。
より低速な PIO モードを試したり、
二番目のチャンネルを外してみて問題が解決するかどうか見てみてください。

<!--O
<item> Use as short cable as possible, but do not forget the
30 cm minimum separation for ultra SCSI
and 60 cm separation for differential SCSI.
-->
<item>ケーブルはできるだけ短くしましょう。しかし
ultra SCSI の場合には最低 30 cm の間隔が、
ディファレンシャル SCSI の場合は 60 cm の間隔が必要なことも忘れないように。

<!--O
<item> Avoid long stubs between the cable and the drive, connect
the plug on the cable directly to the drive without an extension.
-->
<item>ケーブルとデバイスの間に長いスタブ (stub) を用いるのは止め、
ケーブルのプラグはドライブに直に接続するようにしましょう。

<!--O
<item> SCSI Cabling limitations:
-->
<item>SCSI の配線に置ける制限一覧:
<tscreen><verb>

Bus Speed (MHz)         |    Max Length (m)
--------------------------------------------------
 5			|	 6
10  (fast)		|	 3
20  (fast-20 / ultra)	|	 3 (max 4 devices), 1.5 (max 8 devices)
xx  (differential)	|	25 (max 16 devices
--------------------------------------------------

</verb></tscreen>

<!--O
<item> Use correct termination for SCSI devices and at the correct
positions: both ends of the SCSI chain. Remember the host adapter
itself may have on board termination.
-->
<item>SCSI デバイスのターミネーションは
正しい位置のものを有効にしましょう。
SCSI チェーンの両端です。
ホストアダプタにもオンボードのターミネーションがついているかもしれません。

<!--O
<item> Do not mix shielded or unshielded cabling, do not wrap
cables around metal, try to avoid proximity to metal parts along
parts of the cabling. Any such discontinuities can cause impedance
mismatching which in turn can cause reflection of signals which
increases noise on the cable.
This problems gets even more severe in the case of multi channel
controllers.
Recently someone suggested wrapping bubble plastic around the cables
in order to avoid too close proximity to metal, a real problem inside
crowded cabinets.
-->
<item>シールドケーブルとシールド無しのケーブルを混ぜて使わない、
ケーブルを金属の周りに巻かない、
金属部分を配線から遠ざけるようにする、などの注意をしてください。
配線に不連続な部分があると、そこでインピーダンスのミスマッチが生じ、
信号の反射が起こってケーブルのノイズとなってしまいます。
この問題はマルチチャンネルのコントローラではよりシビアになります。
最近、発泡プラスチックでケーブルの周りを覆い、
ケーブルが金属部分に近づきすぎないようにすると良い、
と教えてくれた人がいました。
でも本当の問題は、ケースの中が混んでいることにあるのですよね。
</itemize>

<!--O
More information on SCSI cabling and termination can be found at
<!-\- <url url="http://resource.simplenet.com/files/68_50_n.htm"
    name="other"> -\-> various
web pages around the net.
-->
SCSI の配線や終端処理に関するより詳しい情報は
ネットのたくさんの web ページに書かれています。

<!--O
<sect1>Host Adapters
-->
<sect1>ホストアダプタ
<p>
<nidx>disk!adapters</nidx>
<nidx>disk!host adapters</nidx>

<!--O
This is the other end of the interface from the drive, the part
that is connected to a computer bus. The speed of the computer
bus and that of the drives should be roughly similar, otherwise
you have a bottleneck in your system. Connecting a RAID 0
disk-farm to a ISA card is pointless. These days most computers
come with 32 bit PCI bus capable of 132 MB/s transfers which
should not represent a bottleneck for most people in the near
future.
-->
ドライブからのインターフェースケーブルを繋ぎ、
コンピュータのバスとの仲立ちをします。
コンピュータバスの速度とドライブの速度は同程度のものを利用すべきで、
そうでないとどちらかがボトルネックになります。
例えば RAID 0 のディスクセットを
ISA のバスに繋いだりするとそういうことになります。
最近のコンピュータのほとんどでは
32 ビットの PCI バスを使うことができます。
これは 132 MB/s の転送速度を持っていますので、
しばらくの間はボトルネックになることなく利用できるでしょう。

<!--O
As the drive electronic migrated to the drives the remaining part
that became the (E)IDE interface is so small it can easily fit into
the PCI chip set. The SCSI host adapter is more complex and often
includes a small CPU of its own and is therefore more expensive and
not integrated into the PCI chip sets available today. Technological
evolution might change this.
-->
ドライブの制御回路の大部分がドライブ本体に収められるようになると、
残りの部分である (E)IDE インターフェースは非常にコンパクトになり、
PCI のチップセットに標準的に用意されるようになりました。
SCSI ホストアダプタはもう少し複雑で、
専用の CPU を使ったりすることも多いため、 IDE に比べて高価です。
まだ PCI チップセットにも取り込まれていないようです。
もちろん技術が進歩すれば状況は変わるでしょう。

<!--O
Some host adapters come with separate caching and intelligence but as
this is basically second guessing the operating system the gains are
heavily dependent on which operating system is used. Some of the more
primitive ones, that shall remain nameless, experience great gains.
Linux, on the other hand, have so much smarts of its own that the
gains are much smaller.
-->
ホストアダプタには独自のキャッシュや拡張制御機能を持っているものもあります。
しかしこれは本来 OS の機能のはずなので、
使っている OS によって効果があったりなかったりします。
原始的な OS (特に名を秘す :-) では高い効果が得られることもありますが、
Linux はもともと良くできているので、
これらの機能によって得られる効果はたいした物ではありません。

<!--O
Mike Neuffer, who did the drivers for the DPT controllers, states that
the DPT controllers are intelligent enough that given enough cache
memory it will give you a big push in performance and suggests that
people who have experienced little gains with smart controllers just
have not used a sufficiently intelligent caching controller.
-->
DPT コントローラのドライバを書いた Mike Neuffer によれば、
DPT のコントローラはとても賢く、
充分なキャッシュメモリをあてがってやれば非常に性能が向上するそうです。
またこの事から彼は、
インテリジェントな SCSI コントローラで性能が向上しないのは、
キャッシュコントローラの方の問題ではないかと言っています。

<!--O
<sect1>Multi Channel Systems
-->
<sect1>マルチチャンネルシステム
<p>
<nidx>disk!multi-channel</nidx>
<!--O
In order to increase throughput it is necessary to identify the most
significant bottlenecks and then eliminate them. In some systems, in
particular where there are a great number of drives connected, it is
advantageous to use several controllers working in parallel, both for
SCSI host adapters as well as IDE controllers which usually have 2
channels built in. Linux supports this.
-->
スループットを上げるには、最大のボトルネックを特定し、
それを排除する必要があります。
システムによっては (特にたくさんのドライブを接続しているシステムでは)
複数のコントローラを並列動作させることで効果が得られることがあります。
これは SCSI でも IDE でも同じです
(IDE はもともと 2 チャンネル付いているハードウェアが多いでしょう)。
Linux でもこのような動作はサポートされています。

<!--O
Some RAID controllers feature 2 or 3 channels and it pays to spread
the disk load across all channels. In other words, if you have two
SCSI drives you want to RAID and a two channel controller, you should
put each drive on separate channels.
-->
RAID コントローラの中には、二つまたは三つのチャンネルが付いていて、
ディスクアクセスを別々のチャンネルに振り分けることができるようなものも
存在しています。別の言い方をすれば、
2 チャンネルのコントローラに対して
RAID にしたい 2 台の SCSI ドライブがある場合には、
それらは別々のチャンネルに接続すべきだ、ということです。

<!--O
<sect1>Multi Board Systems
-->
<sect1>マルチボードシステム
<p>
<nidx>disk!multi-board</nidx>
<!--O
In addition to having both a SCSI and an IDE in the same machine
it is also possible to have more than one SCSI controller. Check
the SCSI-HOWTO on what controllers you can combine. Also you will
most likely have to tell the kernel it should probe for more than
just a single SCSI or a single IDE controller. This is done using
kernel parameters when booting, for instance using LILO.
Check the HOWTOs for SCSI and LILO for how to do this.
-->
一台のマシンには SCSI と IDE の両方を繋ぐことができますが、
さらに 2 つ以上の SCSI コントローラを接続することもできます。
可能なコントローラの組合せは SCSI-HOWTO をチェックしてください。
さらに、複数の SCSI, IDE コントローラをプローブするように
カーネルに教えてやる必要があるでしょう。
これはブート時にカーネルにパラメータを与えることによって実現します。
例えば LILO などが使えます。これには SCSI や LILO の HOWTO
をチェックしてください。

<!--O
Multi board systems can offer significant speed gains if you
configure your disks right, especially for RAID0. Make sure you
interleave the controllers as well as the drives, so that you
add drives to the md RAID device in the right order.
If controller 1 is connected to drives <tt/sda/ and <tt/sdc/
while controller 2 is connected to drives <tt/sdb/ and <tt/sdd/
you will gain more paralellicity by adding in the order of
<tt/sda - sdc - sdb - sdd/ rather than <tt/sda - sdb - sdc - sdd/
because a read or write over more than one cluster will be more
likely to span two controllers.
-->
マルチボードのシステムでは、ディスクの配置を正しく設定すれば、
大きな速度性能の向上が期待できます (とくに RAID 0 では)。
コントローラーやドライブを互い違いにして、
md の RAID デバイスに正しい順序でドライブを追加してください。
コントローラ 1 にドライブ <tt/sda/ と <tt/sdc/
が、コントローラ 2 にドライブ <tt/sdb/ と <tt/sdd/
が接続されていたとしますと、並列性を最大にするには
<tt/sda - sdc - sdb - sdd/ の順序で繋ぐことです。
なぜなら互い違いに接続すると、
2 クラスタ以上の読み書きが二つのコントローラにまたがるようになるからです。
<tt/sda - sdb - sdc - sdd/ ではあまり効果が上がりません。

  <label id="drive-names">


<!--O
The same methods can also be applied to IDE. Most motherboards
come with typically 4 IDE ports:
-->
同じ手法は IDE にも使えます。ほとんどのマザーボードでは、
4 つの IDE ポートが使えます。
<itemize>
<item> <tt/hda/ primary master
<item> <tt/hdb/ primary slave
<item> <tt/hdc/ secondary master
<item> <tt/hdd/ secondary slave
</itemize>
<!--O
where the two primaries share one flat cable and the secondaries
share another cable. Modern chipsets keep these independent.
Therefore it is best to RAID in the order <tt/hda - hdc - hdb - hdd/
as this will most likely parallelise both channels.
-->
ここで primary の 2 台、
secondary の 2 台はそれぞれフラットケーブルを共有します。
先進的なチップセットでは、この二組はそれぞれ独立しています。
したがって RAID を構成するときの最適な順序は
<tt/hda - hdc - hdb - hdd/ で、
このとき両チャンネルの並列性がもっとも期待できることになります。

<!--O
<sect1>Speed Comparison
-->
<sect1>速度比較
<p>
<nidx>disk!speed comparison</nidx>
<!--O
The following tables are given just to indicate what speeds are
possible but remember that these are the theoretical maximum
speeds. All transfer rates are in MB per second
and bus widths are measured in bits.
-->
以下の表は転送速度をまとめたものです。
ただしこれらは理論上の最大値に過ぎないことに注意してください。
転送速度の単位は MB/s です。バスの幅の単位はビットです。

<!--O
<sect2>Controllers
-->
<sect2>コントローラ
<p>
<nidx>disk!speed comparison!controllers</nidx>
<tscreen><verb>
IDE		:	 8.3 - 16.7
Ultra-ATA	:	33 - 66

SCSI		:
			Bus width (bits)

Bus Speed (MHz)		|	 8	16	32
--------------------------------------------------
 5			|	 5	10	20
10  (fast)		|	10	20	40
20  (fast-20 / ultra)	|	20	40	80
40  (fast-40 / ultra-2) |	40	80	--
--------------------------------------------------
</verb></tscreen>


<!--O
<sect2>Bus Types
-->
<sect2>バスの形式
<p>
<nidx>disk!speed comparison!bus types</nidx>
<tscreen><verb>

ISA		:	 8-12
EISA		:	33
VESA		:	40    (Sometimes tuned to 50)

PCI
			Bus width (bits)

Bus Speed (MHz)		|	32	64
--------------------------------------------------
33			|	132	264
66 			|	264	528
--------------------------------------------------
</verb></tscreen>

<!--O
<sect1>Benchmarking
-->
<sect1>ベンチマーク
<p>
<nidx>disk!benchmarking</nidx>
<nidx>disk!benchmarking!bonnie</nidx>
<nidx>disk!benchmarking!iozone</nidx>
<nidx>disk!Bonnie Raitt</nidx>
<!--O
This is a very, very difficult topic and I will only make a few
cautious comments about this minefield. First of all, it is more
difficult to make comparable benchmarks that have any actual meaning.
This, however, does not stop people from trying...
-->
これはとても、とっても難しい問題です。
ここではこの地雷原に対する警告をいくつか挙げるにとどめておきます。 
まず、実際に何らかの意味を持つベンチマークを行い、
この結果から有益な結論を導き出すのは、とても難しいことなんです。
とはいっても、これくらいでやめるような人はいませんよね...

<!--O
Instead one can use benchmarking to diagnose your own system, to
check it is going as fast as it should, that is, not slowing down.
Also you would expect a significant increase when switching from
a simple file system to RAID, so a lack of performance gain will
tell you something is wrong.
-->
どちらかというと、自分自身のシステムが以前と同じくらい速いままであるか
(つまり、遅くなっていないか) を診断するために
ベンチマークを使うのがいいでしょう。
また例えば、単純なファイルシステムから
RAID に変更した場合はかなりの効果が見込めるはずですから、
性能に変化がなければどこかがおかしい、などのチェックにも使えるでしょう。

<!--O
When you try to benchmark you should not hack up your own, instead
look up <tt/iozone/ and <tt/bonnie/ and read the documentation very
carefully. In particular make sure your buffer size is bigger than
your RAM size, otherwise you test your RAM rather than your disks
which will give you unrealistically high performance.
-->
ベンチマークを行うときには、自分独自の方法は使わず、
<tt/iozone/ や <tt/bonnie/ を参照するようにしましょう。
これらの文書を隅々まで読むようにしてください。
特にバッファのサイズは必ず RAM のサイズより大きくしてください。
さもないとディスクではなく RAM のテストをすることに
なってしまい、非現実的に高い性能が得られてしまいます。

<!--O
A very simple benchmark can be obtained using <tt/hdparm -tT/ which
can be used both on IDE and SCSI drives.
-->
非常に簡単ではありますが、
<tt/hdparm -tT/ でもベンチマークを行うことができます。
これは IDE のドライブでも SCSI でも使えます。

<!-- More information about this is coming soon. -->
<!--O
For more information on benchmarking and software for a number of
platforms, check out
<url url="http://www.acnc.com/benchmarks.html"
    name="ACNC">
benchmark page
as well as
<!-\- <url url="http://www.spin.ch/&tilde;tpo/bench.html"  000502 -\->
<url url="http://spin.ch/&tilde;tpo/bench/"
    name="this one">
and also
<!-\- <url url="http://metalab.unc.edu/LDP/HOWTO/Benchmarking-HOWTO.html" -\->
<url url="http://www.linuxdoc.org/HOWTO/Benchmarking-HOWTO.html"
    name="The Benchmarking-HOWTO">.
-->
ベンチマークや各種プラットフォームにおけるソフトウェアに
関するより多くの情報は
<url url="http://www.acnc.com/benchmarks.html"
    name="ACNC">
のベンチマークページを見てください。
<url url="http://spin.ch/&tilde;tpo/bench/"
    name="こちらのページ">
や
<url url="http://www.linuxdoc.org/HOWTO/Benchmarking-HOWTO.html"
    name="The Benchmarking-HOWTO">.
などもどうぞ。

<!--O
There are also official home pages for
<url url="http://www.textuality.com/bonnie/"
    name="bonnie">, 
<url url="http://www.coker.com.au/bonnie++/"
    name="bonnie++">
and
<url url="http://www.iozone.org"
    name="iozone">.
-->
現在では
<url url="http://www.textuality.com/bonnie/"
    name="bonnie">, 
<url url="http://www.coker.com.au/bonnie++/"
    name="bonnie++">,
<url url="http://www.iozone.org"
    name="iozone">
には、それぞれ公式ページもあります。

<!--O
Trivia: Bonnie is intended to locate bottlenecks, the name is a tribute
to Bonnie Raitt, "who knows how to use one" as the author puts it.
-->
雑学: Bonnie はローカルなボトルネックの発見用のもので、
名前は Bonnie Raitt, 「ボトルネックの使い方を知ってるひと」
にちなんでつけた、と著者は書いています。
(訳注: Bonnie Raitt はギタリストです :-)

<!--O
<sect1>Comparisons
-->
<sect1>比較検討
<p>
<nidx>disk!comparisons</nidx>
<!--O
SCSI offers more performance than EIDE but at a price.  Termination
is more complex but expansion not too difficult.  Having more than
4 (or in some cases 2) IDE drives can be complicated, with wide SCSI
you can have up to 15 per adapter.  Some SCSI host adapters have
several channels thereby multiplying the number of possible drives
even further.
-->
SCSI の性能は EIDE より高いですが、値段も高くなります。
SCSI ではケーブル終端の処理が面倒ですが、拡張は楽です。
4 台 (場合によっては 2 台) 以上の IDE ドライブを使うのは大変ですが、
wide SCSI なら 15 台まで簡単に使えます。
複数のチャンネルを持っている SCSI ホストアダプタなら、
この台数はチャンネル数を乗じたものになり、さらに多くなります。

<!--O
For SCSI you have to dedicate one IRQ per host adapter which can
control up to 15 drives. With EIDE you need one IRQ for each
channel (which can connect up to 2 disks, master and slave)
which can cause conflict.
-->
SCSI では、ホストアダプタ一つにつき一つの IRQ が必要で、
これで 15 台のドライブをまかなえます。これに対して EIDE では
IRQ がチャンネル一つ (ディスク二台までつなげます) に一つ必要で、
これは conflict の原因になるかもしれません。

<!--O
RLL and MFM is in general too old, slow and unreliable to be of much
use.
-->
RLL と MFM は一般的に言って古すぎます。
たいていの用途には速度、信頼性とも足りないでしょう。


<!--O
<sect1>Future Development
-->
<sect1>将来の開発予定
<p>
<nidx>disk!future development</nidx>
<!-- c't 9/97: This is no longer future...
The general trend is for faster and faster devices for every update
in the specifications. ATA-3 is just out but does not define faster
transfers, that could happen in ATA-4 which is under way. Quantum
has already released DMA/33 and recent motherboard chip sets now
supports this standard.
-->

<!--O
SCSI-3 is under way and will hopefully be released soon. Faster
devices are already being announced, recently an 80 MB/s
and then a 160 MB/s monster specification has been proposed and
also very recently became commercially available.
These are based around the Ultra-2 standard (which used a 40 MHz clock)
combined with a 16 bit cable.
-->
SCSI-3 も策定中で、リリースは近そうです。
より高速のデバイスに関してはすでにアナウンスがあり、
ごく最近には 80 MB/s、
さらには 160 MB/s というモンスター規格も提案され、
ごく最近には商品も出ました。
これらは 40 MHz のクロックを用いる Ultar-2 規格で、
16 ビットのケーブルを用いるものです。

<!--O
Some manufacturers already announce SCSI-3
devices but this is currently rather premature as the standard is not
yet firm. As the transfer speeds increase the saturation point of the
PCI bus is getting closer. Currently the 64 bit version has a limit of
264 MB/s. The PCI transfer rate will in the future be increased from the
current 33 MHz to 66 MHz, thereby increasing the limit to 528 MB/s.
-->
SCSI-3 対応デバイスをアナウンスしたメーカもあるようですが、
標準規格がまだしっかり定まっていない現在では、
これはまだ時期尚早といったものでしょう。
転送速度が上昇するにつれ、
PCI バスのバンド幅がいっぱいになる日も近いかもしれません。
現在の 64 ビットバージョンの PCI バスのリミットは 
264 MB/s となっています。
将来 PCI のクロックは現在の 33 MHz から 66 MHz へ上がるようで、
そうするとリミットは 528 MB/s となります。

<!--O
The ATA development is continuing and is increasing the performance
with the new ATA/100 standard. Since most ATA drives are slower in
sustained transfer from platter than this the performance increase
will for most people be small.
-->
ATA の開発は続いており、
新たな ATA/100 標準の登場に伴って性能も向上を続けています。
ほとんどの ATA デバイスでは、
円板からの定常的な転送速度はこれより遅いので、
ほとんどの人にとっては性能向上は大きなものではありません。

<!--O
More interesting is the Serial ATA development, where the flat cable
will be replaced with a high speed serial link. This makes cabling
far simpler than today and also it solves the problem of cabling
obstructing airflow over the drives.
-->
より興味深いのはシリアル ATA の開発です。
これはフラットケーブルの代わりに高速なシリアル接続を用います。
配線は現在のものよりずっと単純になり、
ケーブリングによってドライブ周りの空気の流れが阻害される問題も解決できます。

<!--O
Another trend is for larger and larger drives. I hear it is possible
to get 75 GB on a single drive though this is rather expensive.
Currently the optimum storage for your money is about 30 GB but also
this is continuously increasing. The introduction of DVD will in the
near future have a big impact, with nearly 20 GB on a single disk you
can have a complete copy of even major FTP sites from around the
world. The only thing we can be reasonably sure about the future
is that even if it won't get any better, it will definitely be bigger.
-->
もうひとつの流れはディスクの巨大化です。最近聞いた話では、
一台のドライブで 75 GB を実現することも可能だそうです
(高価になるでしょうが)。
現在のところではコストパフォーマンスが最も良いのは
30 GB のクラスでしょうが、このサイズも大きくなり続けています。
近い将来に DVD が出てくれば、大きなインパクトが期待できます。
DVD は一枚のディスクに 18 GB を記録できます。
これは世界各地にある有名な FTP サイトをフルコピーできる容量です。
ディスク技術の「質」が上がるかどうかは確言できませんが、
「量」は確実に増えていくでしょう。

<!--O
Addendum: soon after I first wrote this I read that the maximum useful
speed for a CD-ROM was 20x as mechanical stability would be too great
a problem at these speeds. About one month after that again the first
commercial 24x CD-ROMs were available... Currently you can get 40x and
no doubt higher speeds are in the pipeline.
-->
追加：この部分を書いてからすぐ、 CD-ROM の最大速度が 20 倍速となり、
機械的な安定性が大きな問題になるであろうという記事を目にしました。
またその一ヶ月後、今度は 24 倍速の CD-ROM の宣伝が出ていました...
(訳注: もう今では 24 倍も普通になってますね)
おそらく 40x 以上のものが、すでに出荷直前の段階にあることでしょう。

<!--O
<sect1>Recommendations <label id="recommendations">
-->
<sect1>お薦め<label id="recommendations">
<p>
<nidx>disk!recommendations</nidx>
<!--O
My personal view is that EIDE
or Ultra ATA is the best way to start out on your
system, especially if you intend to use DOS as well on your machine.
If you plan to expand your system over many years or use it as a
server I would strongly recommend you get SCSI drives. Currently
wide SCSI is a little more expensive. You are generally more likely
to get more for your money with standard width SCSI. There is also
differential versions of the SCSI bus which increases maximum length
of the cable. The price increase is even more substantial and cannot
therefore be recommended for normal users.
-->
私の個人的な意見では、
システムを初めて作る場合には EIDE または Ultra-ATA が最適です。
特に DOS を同時に使う場合はこれで充分です。
一方システムを何年にもわたって拡張する予定や、
サーバとして使う予定があるのでしたら、
SCSI のドライブを強くお薦めします。
現在のところ wide SCSI はまだ少々高価なようですので、
8 ビット幅の SCSI を選ぶ方がコストパフォーマンスが良いでしょう。
ケーブルの最大長を大きく取れるような SCSI バスの規格もあるようですが、
値段はさらに割高になるので普通のユーザにはお薦めしません。

<!--O
In addition to disk drives you can also connect some types of
scanners and printers and even networks to a SCSI bus.
-->
SCSI バスにはディスクドライブだけではなく、
製品を限ればスキャナやプリンタ、ネットワークなどを繋ぐこともできます。

<!--O
Also keep in mind that as you expand your system you will draw ever
more power, so make sure your power supply is rated for the job and
that you have sufficient cooling. Many SCSI drives offer the option
of sequential spin-up which is a good idea for large systems.
See also
<ref id="power-heating" name="Power and Heating">.
-->
システムの拡張にあたっては、
より大きな電力が必要になることも忘れないでください。
使っている電源の容量が足りるか、
冷却が充分かどうかにも気をつけなければなりません。
SCSI ドライブの多くはスピンアップを順番に行う機能を持っているので、
大きなシステムにはこれを用いるのが良いでしょう。
<ref id="power-heating" name="電力と発熱">
の節にある情報も参考にしてください。

<!--
I do not want to say too much about low level hardware here but I have
to make an exception for SCSI. Some people have a bit of trouble with
this and in the majority of cases the cause is sub standard cabling.
Certain SCSI adapters are known to be very sensitive to the quality
of the cables, see the SCSI HOWTO.
The importance of correct cabling and termination cannot be
overemphasized, read the manuals carefully. Also with the 20MHz Ultra
standard you now also have to keep in mind that there is now also a
minimum distance of 30cm between devices.
 -->

<!-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 -->

<!-- 
<sect>Considerations
<p>
<nidx>disk!considerations</nidx>
The starting point in this will be to consider where you are and what
you want to do. The typical home system starts out with existing
hardware and the newly converted Linux user will want to get the most
out of existing hardware. Someone setting up a new system for a
specific purpose (such as an Internet provider) will instead have to
consider what the goal is and buy accordingly. Being ambitious I will
try to cover the entire range.

Various purposes will also have different requirements regarding file
system placement on the drives, a large multiuser machine would
probably be best off with the <tt>/home</tt> directory on a
separate disk, just to give an example.

In general, for performance it is advantageous to split most things
over as many disks as possible but there is a limited number of
devices that can live on a SCSI bus and cost is naturally also a
factor. Equally important, file system maintenance becomes more
complicated as the number of partitions and physical drives increases.
 -->


<!--O
<sect>File System Structure
-->
<sect>ファイルシステムの構造
<p>
<nidx>disk!filesystem structure</nidx>
<!--O
Linux has been multi tasking from the very beginning where a number
of programs interact and run continuously. It is therefore important
to keep a file structure that everyone can agree on so that the system
finds data where it expects to. Historically there has been so many
different standards that it was confusing and compatibility was
maintained using symbolic links which confused the issue even further
and the structure ended looking like a maze.
-->
Linux は開発のごく初期からマルチタスクで、そこではたくさんの
プログラムが相互作用しながら共存しています。したがって
ファイル構造をみんなが納得できるように保ち、システムが必要な
データはそれと分かる場所に配置することが大切です。歴史的には
異なった規格がとてもたくさん存在していたため、混乱の原因となりました。
それらの互換性を取るためにシンボリックリンクが多用され、
さらに混乱を引き起こしてファイル構造をまるで迷路のように
してしまったのです。

<nidx>disk!FSSTND</nidx>
<!--O
In the case of Linux a standard was fortunately agreed on early on
called the <em/File Systems Standard/ (FSSTND) which today is used
by all main Linux distributions.
-->
幸いなことに Linux の場合には、早いうちに <em/File Systems Standard/
(FSSTND) という規格が合意され、今日の Linux ディストリビューション
のほとんどで用いられるようになりました。

<nidx>disk!FHS</nidx>
<!--O
Later it was decided to make a successor that should also support
operating systems other than just Linux, called
the <em/Filesystem Hierarchy Standard/ (FHS) at version 2.1 currently.
This standard is under continuous development and will
soon be adopted by Linux distributions.
-->
その後この後継規格として、 Linux 以外の
OS でも用いることのできるようなものを策定することになりました。
これは <em/Filesystem Hierarchy Standard/ (FHS) と呼ばれ、
現在は version 2.1 です。この規格はまだ開発も継続中ですが、
そのうち各ディストリビューションに採用されることでしょう。

<!--O
I recommend not trying to roll your own structure as a lot of
thought has gone into the standards and many software packages
comply with the standards. Instead you can read more about this
at the
<url url="http://www.pathname.com/fhs/"
    name="FHS home page">.
-->
自前の構造を作ってしまうことはあまりお薦めしません。
FHS には多くの考えが盛り込まれており、多くのソフトウェア
パッケージがこの規格に準拠してきているからです。
<url url="http://www.pathname.com/fhs/"
    name="FHS home page">
から、より多くの情報を読んでみると良いでしょう。

<!--O
This HOWTO endeavours to comply with FSSTND
and will follow FHS when distributions become available.
-->
この HOWTO は FSSTND に準拠しようと努力しています。
FHS 向けのディストリビューションが出てきたら、
FHS に準拠したものにする予定です。

<!--O
<sect1>File System Features
-->
<sect1>ファイルシステムの特徴
<p>
<nidx>disk!filesystem features</nidx>
<!--O
The various parts of FSSTND have different requirements regarding
speed, reliability and size, for instance losing root is a pain
but can easily be recovered. Losing <tt>/var/spool/mail</tt> is a
rather different issue. Here is a quick summary of some essential
parts and their properties and requirements. Note that this is
just a guide, there can be binaries in <tt>etc</tt> and
<tt>lib</tt> directories, libraries in <tt>bin</tt> directories
and so on.
-->
FSSTND 中の様々な構成要素に対しては、
それぞれ異なった速度・信頼性・容量が必要になります。
例えばルートパーティションを失っても、
痛手ではありますが修復は比較的簡単です。
一方 <tt>/var/spool/mail</tt> を失うのは非常にまずいでしょう。
ここではいくつかの主要なディレクトリについて、
それぞれの特徴と要求される性能とを簡単にまとめてあります。
この部分は一般的な話であることを承知しておいてください。
実行バイナリが <tt/etc/ や <tt/lib/ ディレクトリに置かれたり、
ライブラリファイルが
<tt/bin/ ディレクトリに置かれたりすることなども実際にはあります。

<!--O
<sect2>Swap
-->
<sect2>スワップ領域
<p>
<nidx>disk!swap</nidx>
<descrip>
<!--O
<tag/Speed/ Maximum! Though if you rely too much on swap you
should consider buying some more RAM. Note, however, that on
many old Pentium PC motherboards the cache will not work on RAM above 128 MB.
-->
<tag/速度/
最速のものを。しかしスワップに頼りすぎているような場合は
RAM を買い足すことを考えた方が良いでしょう。
ただし古い Pentium PC マザーボードの多くでは、
128 MB 以上の RAM にはキャッシュが効かないかも知れないことに注意してください。

<!--O
<tag/Size/ Similar as for RAM. Quick and dirty algorithm:
just as for tea: 16 MB for the machine and 2 MB for each user. Smallest
kernel run in 1 MB but is tight, use 4 MB for general work and light
applications, 8 MB for X11 or GCC or 16 MB to be comfortable.
(The author is known to brew a rather powerful cuppa tea...)
-->
<tag/容量/
考え方は RAM の場合と同じです。簡単な計算法をお教えしましょう。
紅茶の入れ方と一緒です。マシンに 16 MB、各ユーザに 2 MB ずつ。
最小のカーネルは 1 MB でもギリギリ走ります。
普通の仕事や軽めのアプリケーションには 4 MB、X11 や gcc
には 8 MB 用意しましょう。 16 MB あれば快適でしょう。
(著者は濃い目の紅茶を淹れることで知られています...)

<!--O
Some suggest that swap space should be 1-2 times the size of the
RAM, pointing out that the locality of the programs determines how
effective your added swap space is. Note that using the same
algorithm as for 4BSD is slightly incorrect as Linux does not
allocate space for pages in core.
-->
スワップとして RAM の 1〜2 倍を勧める人もいます。
またどんなプログラムが動いているかによって
スワップスペースの有効性が決まるという指摘もあります。
4BSD の場合に使われる見積もり方法は
Linux の場合にはあまり適当ではありません。
Linux は core の中にページングのための領域を確保しないからです。

<!--O
A more thorough approach is to consider swap space plus RAM as
your total working set, so if you know how much space you will
need at most, you subtract the physical RAM you have and that
is the swap space you will need.
-->
もっと完全なやり方は、スワップスペースと RAM の和を
あなたの用いるワーキングセットの総計と考えることです。
自分が必要とするメモリ空間の最大量を知っているなら、
そこから物理 RAM の量をひいてスワップの量とすれば良いわけです。

<!--O
There is also another reason to be generous when dimensioning
your swap space: memory leaks. Ill behaving programs that do not free
the memory they allocate for themselves are said to have a memory leak.
This allocation remains even after the offending program has stopped
so this is a source of memory consumption. Once all physical RAM and
swap space are exhausted the only solution is to reboot and start over.
Thankfully such programs are not too common but should you come across
one you will find that extra swap space will buy you extra time between
reboots.
-->
スワップのサイズを決めるときには、気前良くたくさん割り当てた方が
良いかもしれません。これには理由があります。メモリリークです。
お作法を守らないプログラムでは、
自分に割り当てたメモリを解放しないものがあります。
これを「メモリリークがある」と表現します。
このようなプログラムに割り当てられたメモリは、
この悪党プログラムが終了したあとでも解放されず、
したがってメモリ消費の原因になります。
物理 RAM とスワップスペースがすべて使われてしまえば、
解決法はただ一つ、再起動してやり直すしかありません。
ありがたいことにこのようなプログラムはそう多くはありませんが、
でもいつかそんなプログラムに出くわしたときには、
余分にとっておいたスワップスペースのおかげで
再起動の間の時間が長く取れるようになっていることがわかるでしょう。

<!--O
Also remember to take into account the type of programs you use.
Some programs that have large working sets, such as 
<!-\- finite element method (FEM) -\->
image processing software
have huge data structures loaded in RAM rather than
working explicitly on disk files. Data and computing intensive
programs like this will cause excessive swapping if you have less
RAM than the requirements.
-->
使っているプログラムによっても話は変わってきます。
画像処理ソフトのように大きな実行領域を必要とするプログラムでは、
RAM に巨大なデータ構造がロードされ、
ディスク上でデータが扱われることはあまりありません。
このようなデータ負荷および CPU 負荷が高いプログラムでは、
必要な RAM が無いとスワップの嵐に見舞われることになります。

<!--O
Other types of programs can lock their pages into RAM. This can be
for security reasons, preventing copies of data reaching a swap device
or for performance reasons such as in a real time module. Either way,
locking pages reduces the remaining amount of swappable memory and
can cause the system to swap earlier then otherwise expected.
-->
また、自分自身の実行イメージ (の一部) を
RAM にロックしてしまうプログラムもあります (ページロックと呼ばれます)。
セキュリティの問題から
データをスワップデバイスへコピーできないようなプログラムや、
あるいは高速処理が必要なリアルタイム指向のプログラムなどが該当します。
ページロックが行われるとスワップ可能なメモリ量が減りますから、
予想より早い段階でスワップが起こることになります。

<!--O
In <tt/man 8 mkswap/ it is explained that each swap partition can
be a maximum of just under 128 MB in size for 32-bit machines
and just under 256 MB for 64-bit machines.
-->
<tt/man 8 mkswap/ によれば、スワップパーティションひとつあたりについて、
32 ビットマシンなら 128 MB にちょっと足りないくらい、
また 64 ビットマシンなら
256 MB にちょっと足りないくらいの大きさを割り当てることができます。

<!--O
This however changed with kernel 2.2.0 after which the limit is 2 GB.
The man page has been updated to reflect this change.
-->
しかしカーネル 2.2.0 以降では、この制限は 2 GB に変更されました。
man ページもこの変更を受けて更新されました。

<!--O
<tag/Reliability/ Medium. When it fails you know it pretty quickly and
failure will cost you some lost work. You save often, don't you?
-->
<tag/信頼性/
中程度。障害が起こったときにはすぐわかりますし、
それによって失うものもたいしたことはないでしょう。
セーブはこまめにしてるでしょ？

<!--O
<tag/Note 1/ Linux offers the possibility of interleaved swapping
across multiple devices, a feature that can gain you much. Check out
"<tt>man 8 swapon</tt>" for more details. However, software raiding
<tt>swap</tt> across multiple devices adds more overheads than you gain.
-->
<tag/注意 1/
Linux では複数のデバイスにまたがるかたちでスワップを配置できます。
この機能は使ってみると意外と便利です。詳しい内容については
&dquot;<tt/man 8 swapon/&dquot;
を見てください。ただしソフトウェア版 RAID を複数のデバイスに用いて、
それをスワップにするのはオーバーヘッドのほうが大きいでしょう。

<!--O
Thus the <tt>/etc/fstab</tt> file might look like this:
<tscreen><verb>
/dev/sda1       swap            swap    pri=1           0       0
/dev/sdc1       swap            swap    pri=1           0       0
</verb></tscreen>
Remember that the <tt/fstab/ file is <em/very/ sensitive to the formatting
used, read the man page carefully and do <em/not/ just cut and paste
the lines above.
-->
この場合の <tt>/etc/fstab/</tt> ファイルの内容は以下のようになるでしょう。
<tscreen><verb>
/dev/sda1       swap            swap    pri=1           0       0
/dev/sdc1       swap            swap    pri=1           0       0
</verb></tscreen>
<tt/fstab/ は書式に非常に厳しいので、
必ず man ページをしっかり読むようにしてください。
上の行をカット &amp; ペーストするだけじゃ駄目ですからね。

<!--O
<tag/Note 2/ Some people use a RAM disk for swapping or some other
file systems. However, unless you have some very unusual requirements
or setups you are unlikely to gain much from this as this cuts into
the memory available for caching and buffering.
-->
<tag/注意 2/
RAM ディスクをスワップなどのファイルシステムに使っている人がいるようです。
しかし非常に特殊な場合を除けば、この方法はあまり得にはならないでしょう。
キャッシュやバッファに使えるメモリが減少してしまうからです。

<!--O
<tag/Note 2b/ There is once exception: on a number of badly designed
motherboards the on board cache memory is not able to cache all the
RAM that can be addressed. Many older motherboards could accept 128 MB
RAM but only cache the lower 64 MB. In such cases it would improve the
performance if you used the upper (uncached) 64 MB RAM for RAMdisk
based swap or other temporary storage.
-->
<tag/注意 2b/
ひとつだけ例外があります。
世の中には設計の悪いマザーボードがたくさんあって、
アドレスできる RAM のすべてをキャッシュできない場合があります。
古いマザーボードの多くでは、
メモリは 128 MB 使えてもキャッシュはその内の 64 MB にしか効かないのです。
このような場合には、
上位の (キャッシュされない) 64 MB の RAM をラムディスクにして、
スワップ領域や一時記憶領域にした方が良い場合があります。

</descrip>


<!--O
<sect2>Temporary Storage (<tt>/tmp</tt> and <tt>/var/tmp</tt>)
-->
<sect2>一時記憶領域 (<tt>/tmp</tt> と <tt>/var/tmp</tt>)
<p>
<nidx>disk!temporary storage</nidx>
<descrip>
<!--O
<tag/Speed/ Very high. On a separate disk/partition this will
reduce fragmentation generally, though <tt/ext2fs/ handles fragmentation
rather well.
-->
<tag/速度/
高速のものを。別のディスクやパーティションにおけば、フラグメンテーショ
ンを減らせます。もっとも ext2fs はフラグメンテーションをうまく扱うこと
ができますので、それほど気にしなくても良いかもしれません。

訳注: フラグメンテーション (fragmentation):
頻繁にアクセスされるディスク領域においては、
ファイルの保存領域が断片化しやすくなります。
この現象を一般にフラグメンテーションと呼び、
ファイルアクセス性能の低下の一因となります。

<!--O
<tag/Size/ Hard to tell, small systems are easy to run with just
a few MB but these are notorious hiding places for stashing files
away from prying eyes and quota enforcement and can grow without
control on larger machines. Suggested: small home machine: 8 MB,
large home machine: 32 MB, small server: 128 MB, and large
machines up to 500 MB (The machine used by the author at work has 1100
users and a 300 MB <tt>/tmp</tt> directory). Keep an eye on these directories,
not only for hidden files but also for old files. Also be prepared that
these partitions might be the first reason you might have to resize
your partitions.
-->
<tag/容量/
難しいです。小さなシステムなら数 MB でも足りるでしょう。
しかしこれらのディレクトリは、
他のユーザや quota の制限から
ファイルを隠すことのできる場所として知られているので、
マルチユーザの大きなマシンでは際限無く大きくなることがあります。
以下は筆者のお勧めです: 家で使う場合は、小さなマシンなら 8 MB、
大きめの場合 32 MB。小さなサーバでは 128 MB、大きなサーバで最大 500 MB。
なお筆者が仕事で使っているマシンでは
1100 名のユーザに対し <tt>/tmp</tt> ディレクトリを 300 MB とっています。
これらのディレクトリには目を配っておき、
隠し属性のファイルや古いファイルに注意しましょう。
パーティションの切り直しが必要になるのは、
ここのディレクトリが原因であることが多いようです。

<!--O
<tag/Reliability/ Low. Often programs will warn or fail gracefully when
these areas fail or are filled up. Random file errors will of course
be more serious, no matter what file area this is.
-->
<tag/信頼性/
低くて良いです。これらの領域が壊れていたり一杯だったりしても、
大抵のプログラムは礼儀正しくできていますので、
警告を発するか停止してくれるでしょう。
もちろん偶発的なファイルエラーは深刻な問題ですが、
これはどんなファイル領域でも同じことです。

<!--O
<tag/Files/ Mostly short files but there can be a huge number of
them. Normally programs delete their old <tt>tmp</tt> files but if somehow an
interruption occurs they could survive. Many distributions have a policy
regarding cleaning out <tt>tmp</tt> files at boot time, you might want to
check out what your setup is.
-->
<tag/ファイル/
ほとんどは小さなファイルですが、膨大な数になります。
普通のプログラムは使用した一時ファイルを消しますが、
割り込みがあったりすると残ってしまうこともあります。
多くの配布パッケージでは
<tt/tmp/ ファイルを起動時に消去するような設定がなされています。
自分のシステムではどうなっているか確認しておくと良いでしょう。

<!--O
<tag/Note1/ In FSSTND there is a note about putting <tt>/tmp</tt> on
RAM disk. This, however, is not recommended for the same reasons
as stated for swap. Also, as noted earlier, do not use flash RAM
drives for these directories. One should also keep in mind that some
systems are set to automatically clean <tt>tmp</tt> areas on rebooting.
-->
<tag/注意 1/
FSSTND では <tt>/tmp</tt> を
RAM ディスクに置くと良いといった記述があります。
しかしスワップのところで述べたのと同じ理由で、
これはおすすめできません。また、これも先に述べましたが、
フラッシュ RAM のドライブをこれらのディレクトリに割り当てるのもやめましょう。

<!--O
<tag/Note2/ Older systems had a <tt>/usr/tmp</tt> but this is no longer
recommended and for historical reasons a symbolic link now makes it
point to one of the other <tt>tmp</tt> areas.
-->
<tag/注意 2/
古いシステムでは <tt>/usr/tmp</tt> があるかもしれませんが、
これはもう推奨されていません。ただし歴史的な理由から、
他の <tt/tmp/ 領域へのシンボリックリンクとして残されていることがあるようです。

</descrip>


<!--O
 (* That was 50 lines, I am home and dry! *)
-->
(* これで何行かな？いま自宅ですが、ノド乾いたなあ。*)

<!--O
<sect2>Spool Areas (<tt>/var/spool/news</tt> and <tt>/var/spool/mail</tt>)
-->
<sect2>スプール領域 (<tt>/var/spool/news</tt> と <tt>/var/spool/mail</tt>)
<p>
<nidx>disk!spool areas</nidx>
<descrip>
<!--O
<tag/Speed/ High, especially on large news servers. News transfer
and expiring are disk intensive and will benefit from fast drives. 
Print spools: low. Consider RAID0 for news.
-->
<tag/速度/
特にニュースサーバ用途には速いものを。
ニュースの配信や消去はディスクを酷使しますので、
速いディスクから得られるメリットは大きいでしょう。
プリントスプールは遅くても良いです。
ニュースには RAID 0 の使用も考えましょう。

<!--O
<tag/Size/ For news/mail servers: whatever you can afford. For
single user systems a few MB will be sufficient if you read
continuously.  Joining a list server and taking a holiday is, on the
other hand, not a good idea.  (Again the machine I use at work
has 100 MB reserved for the entire <tt>/var/spool</tt>)
-->
<tag/容量/
ニュース／メールサーバの場合はできる限り大きなものを。
シングルユーザのシステムで常時読んでいるような場合は数 MB で十分でしょう。
ただしトラフィックの大きいメーリングリストに参加している人が
休暇を取るような場合には、
これでは足りないかも知れません。私が仕事で使っているマシンでは 
<tt>/var/spool</tt> 全体に 100 MB を割り当てています。

<!--O
<tag/Reliability/ Mail: very high, news: medium, print spool: low. If
your mail is very important (isn't it always?) consider RAID for
reliability.
-->
<tag/信頼性/
メールの場合は非常に高い必要があります。ニュースは普通、プリントスプー
ルは低くて良いでしょう。メールが重要なら (普通はそうでしょ？)
信頼性を高めるために RAID の導入を考えましょう。

<!--O
<tag/Files/ Usually a huge number of files that are around a few
KB in size. Files in the print spool can on the other hand be
few but quite sizable.
-->
サイズ数 KB の大きさのファイルが非常にたくさん置かれます。
逆にプリントスプールの場合は、
数は少ないですが各ファイルはかなり大きなものになります。

<!--O
<tag/Note/ Some of the news documentation suggests putting all
the <tt>.overview</tt> files on a drive separate from the news
files, check out all news FAQs for more information.
Typical size is about 3-10 percent of total news spool size.
-->
<tag/注意/
ニュース関連の文書では、
<tt>.overview</tt> ファイルをすべてまとめて、
ニュースファイルとは別のドライブに置くことを勧めているようです。
より詳しくは news に関する FAQ をチェックしてください。
この大きさはニューススプールの総量の 3〜10 パーセントくらいになります。
</descrip>

<!--O
<sect2>Home Directories (<tt>/home</tt>) <label id="home-dirs">
-->
<sect2>ホームディレクトリ (<tt>/home</tt>) <label id="home-dirs">
<p>
<nidx>disk!home directories</nidx>
<descrip>
<!--O
<tag/Speed/ Medium. Although many programs use <tt>/tmp</tt> for temporary
storage, others such as some news readers frequently update files in the
home directory which can be noticeable on large multiuser systems. For
small systems this is not a critical issue.
-->
<tag/速度/
普通です。大抵のプログラムは一時的な保存場所に
<tt>/tmp</tt> を用いますが、
ニュースリーダのように
ホームディレクトリのファイルを頻繁に更新するプログラムもあります。
小さなシステムでは問題にならないでしょうが、
大きなマルチユーザシステムだと気になることがあるかもしれません。

<!--O
<tag/Size/ Tricky! On some systems people pay for storage so this
is usually then a question of finance. Large systems such as 
<url url="http://www.nyx.net/"
    name="Nyx.net">
(which is a free Internet service with mail, news and WWW services)
run successfully with a suggested limit of 100 KB per user and 300 KB as
enforced maximum. Commercial ISPs offer typically about 5 MB in their
standard subscription packages.
-->
<tag/容量/
難しいです。ユーザがディスク容量に対して対価を支払うようなシステムでは、
これはお金の問題になるでしょう。
<url url="http://www.nyx.net/" name="Nyx.net">
はメール、ニュース、WWW といったインターネットサービスを
無料で提供している大きなシステムですが、
ユーザ一人あたり最大 300 KB、推奨 100 KB という制限でうまく稼動しています。
商用プロバイダの通常の契約では 5 MB 程度を利用できる場合が多いようです。

<!--O
If however you are writing books or are doing design work the
requirements balloon quickly.
-->
本を書いたりデザインワークをしているような場合には、
必要な容量はフーセンのようにあっという間に膨らむでしょう。

<!--O
<tag/Reliability/ Variable. Losing <tt>/home</tt> on a single user machine is
annoying but when 2000 users call you to tell you their home
directories are gone it is more than just annoying. For some their
livelihood relies on what is here. You do regular backups of course?
-->
<tag/信頼性/
流動的です。シングルユーザのマシンで
<tt>/home</tt> が失われるのも困ったことではありますが、
2000 人のユーザから
「ホームディレクトリが無くなった」という電話を受けるのとは
「困った」の度合が全然異なるでしょう。
彼らユーザの中には生活の糧となる情報をここに置いている人もいるかもしれません。
もちろん定期的なバックアップはしてますよね？

<!--O
<tag/Files/ Equally tricky. The minimum setup for a single user
tends to be a dozen files, 0.5 - 5 KB in size. Project related files
can be huge though.
-->
<tag/ファイル/
同じく流動的です。ユーザ一人当たりの最小のセットアップでは、
ファイルが数 10 個、サイズは 0.5〜5 KB 程度になるでしょう。
プロジェクト関連のファイルはずっとずっと大きくなるでしょう。

<!--O
<tag/Note1/ You might consider RAID for either speed or
reliability. If you want extremely high speed and reliability you
might be looking at other operating system and hardware platforms anyway.
(Fault tolerance etc.)
-->
<tag/注意 1/
スピードと信頼性を求めるなら RAID を考慮すべきです。
さらなる高速性や信頼性が必要なら、
他の OS やプラットホーム (耐故障システムなど) を考えるべきでしょう。

<!--O
<tag/Note2/ Web browsers often use a local cache to speed up browsing and
this cache can take up a substantial amount of space and cause much disk
activity. There are many ways of avoiding this kind of performance hits,
for more information see the sections on
<ref id="server-home-dirs" name="Home Directories">
and
<ref id="www" name="WWW">.
-->
<tag/注意 2/
多くの Web ブラウザは
ブラウジングを高速化するためにローカルなキャッシュを利用します。
このキャッシュはかなりたくさんの容量を必要としますし、
またディスクに対するアクセス要求が頻繁になります。
これによって生じる性能低下を避ける方法はいくつかあります。
具体的な情報に関しては
<ref id="server-home-dirs" name="ホームディレクトリ">
や
<ref id="www" name="WWW">
の節を参考にしてください。

<!--O
<tag/Note3/ Users often tend to use up all available space on the
<tt>/home</tt> partition. The Linux Quota subsystem is capable of
limiting the number of blocks and the number of inode a single user
ID can allocate on a per-filesystem basis. See the <url
url="http://www.linuxdoc.org/" name="Linux Quota mini-HOWTO"> by
Albert M.C. Tam <tt/bertie (at) scn.org/
for details on setup.
-->
<tag/注意 3/
ユーザーは <tt>/home</tt> に割り当てられた自分のスペースを
簡単に使い切ってしまうものです。
Linux の Quota サブシステムはユーザー ID ひとつあたりに割り当てるブロック数と
inode 数をファイルシステム単位で制限できます。
設定の詳細は Albert M.C. Tam <tt/bertie (at) scn.org/
の書いた
<url url="http://www.linuxdoc.org/" name="Linux Quota mini-HOWTO">
を見てください。

訳注:
<url url="http://www.linux.or.jp/JF/JFdocs/Quota.html"
 name="Quota mini-HOWTO の日本語訳">
は JF にあります。また最新の quota システムのマニュアルの翻訳が
<url url="http://www.linux.or.jp/JM/html/quota/" name="JM Project">
でなされています。

</descrip>


<!--O
<sect2>Main Binaries ( <tt>/usr/bin</tt> and <tt>/usr/local/bin</tt>)<label id="main-binaries">
-->
<sect2>バイナリ (<tt>/usr/bin</tt> と <tt>/usr/local/bin</tt>)
<label id="main-binaries">
<p>
<nidx>disk!main binaries</nidx>
<descrip>
<!--O
<tag/Speed/ Low. Often data is bigger than the programs which are
demand loaded anyway so this is not speed critical. Witness the
successes of live file systems on CD ROM.
-->
<tag/速度/
遅くて良いです。プログラムはデマンドロードされるので、
むしろデータの方が大きいことの方が多いです。
したがって速度は重要ではありません。
CD-ROM 上の live ファイルシステムの成功が証拠です。

訳注: live ファイルシステムとは
CD-ROM 上にルートファイルシステムを置いて直接ブート可能にしたものです。
詳細については
<url url="http://www.pdc.com/wp29.htm">
などをご覧ください。

<!--O
<tag/Size/ The sky is the limit but 200 MB should give you most of
what you want for a comprehensive system. A big system, for software
development or a multi purpose server should perhaps reserve 500 MB
both for installation and for growth.
-->
<tag/容量/
上限は遥か天空の彼方ですが、
大抵のシステムなら 200 MB あれば必要なものの大部分は入るでしょう。
ソフト開発を行うホストや多目的サーバなどの大きなシステムでは
インストール時に 500 MB、 将来のためにさらに
500 MB の領域を確保しておくと良いでしょう。

<!--O
<tag/Reliability/ Low. This is usually mounted under root where all
the essentials are collected. Nevertheless losing all the binaries is
a pain...
-->
<tag/信頼性/
低くて良いでしょう。
このパーティションは普通ルートパーティションにマウントされるでしょうが、
ほんとうに大事なものはルートに入っているでしょうから。
しかしバイナリをすべて失うのは痛いことは痛いですね...

<!--O
<tag/Files/ Variable but usually of the order of 10 - 100 KB.
-->
<tag/ファイル/
いろいろな大きさのファイルがあるでしょうが、だいたい 10〜100 KB
くらいのものが多いでしょう。
</descrip>


<!--O
<sect2>Libraries ( <tt>/usr/lib</tt> and <tt>/usr/local/lib</tt>)
-->
<sect2>ライブラリ (<tt>/usr/lib</tt> と <tt>/usr/local/lib</tt>)
<p>
<nidx>disk!libraries</nidx>
<descrip>
<!--O
<tag/Speed/ Medium. These are large chunks of data loaded often,
ranging from object files to fonts, all susceptible to bloating. Often
these are also loaded in their entirety and speed is of some use here.
-->
<tag/速度/
普通です。ここにはオブジェクトファイルからフォントに至るまで、
頻繁にロードされる図体のでかい (しかも近年さらに拡大傾向にある)
データが置かれます。
これらは一度に全体がロードされるので、
ここに速いディスクを使うのはそれなりの価値があります。

<!--O
<tag/Size/ Variable. This is for instance where word processors
store their immense font files. The few that have given me feedback on
this report about 70 MB in their various <tt>lib</tt> directories.
A rather complete Debian 1.2 installation can take as much as
250 MB which can be taken as an realistic upper limit.
The following ones are some of the largest disk space consumers:
GCC, Emacs, TeX/LaTeX, X11 and perl.
-->
<tag/容量/
流動的です。
例えばワードプロセッサなどが
大量のフォントファイルを保存するような場合もあります。
この文書に対してフィードバックをくれた方の中には、
種々の <tt>lib</tt> ディレクトリに 70 MB 使っている人もいました。
Debian 1.2 をほぼすべてインストールすると、だいたい 250 MB になります。
これを実際の上限と考えておくと良いでしょう。
ディスク食いの最たるものとしては、
GCC, Emacs, TeX/LaTeX, X11, perl などがあります。

<!--O
<tag/Reliability/ Low. See point <ref id="main-binaries" name="Main binaries">.
-->
<tag/信頼性/
低くて良いです。理由は
<ref id="main-binaries" name="バイナリ">
の節で述べたものと同じです。

<!--O
<tag/Files/ Usually large with many of the order of 1 MB in size.
-->
<tag/ファイル/
普通は大きく、 1 MB のオーダーのものが多いでしょう。

<!--O
<tag/Note/ For historical reasons some programs keep executables in
the lib areas. One example is GCC which have some huge binaries in the
<tt>/usr/lib/gcc/lib</tt> hierarchy.
-->
<tag/注意/
歴史的な理由から、いくつかの実行プログラムファイルは lib 領域に置かれ
ています。例えば GCC はいくつかの非常に大きなバイナリファイルを
<tt>/usr/lib/gcc/lib</tt> 以下のディレクトリに置いています。
</descrip>

<sect2>Boot
<p>
<nidx>disk!boot</nidx>
<nidx>disk!1023</nidx>
<nidx>disk!nuni</nidx>
<descrip>
<!--O
<tag/Speed/ Quite low: after all booting doesn't happen that often
and loading the kernel is just a tiny fraction of the time it takes
to get the system up and running.
-->
<tag/速度/
非常に遅くてかまいません。
ブートはそんなにたくさん行われるものではないですし、
カーネルのロードもシステムの立ち上げにかかる時間のほんの一部でしかありません。

<!--O
<tag/Size/ Quite small, a complete image with some extras
fit on a single floppy so 5 MB should be plenty.
-->
<tag/容量/
極めて小さくて良いでしょう。完全なイメージにいくらか追加をしても
1 枚のフロッピーに収まるのですから、 5 MB あれば十分過ぎるでしょう。

<!--O
<tag/Reliability/ High. See section below on Root.
-->
<tag/信頼性/
高い必要があります。以下の Root の部分を参照。

<!--O
<tag/Note 1/ The most important part about the Boot partition is that
on many systems it <em/must/ reside below cylinder 1023. This is a
BIOS limitation that Linux cannot get around.
-->
<tag/注意 1/
Boot パーティションについて最も気をつけなければいけないことは、
これは多くのシステムでは 1023 シリンダ以下の部分に置かなければならない、
ということです。これは Linux では回避できない BIOS の制限なのです。

<!--O
<tag/Note 1a/ The above is not necessarily true for recent IDE systems
and not for any SCSI disks. For more information check the latest
Large Disk HOWTO.
-->
<tag/注意 1a/ 上記は最近の IDE システムには必ずしも
当てはまりません。また SCSI ディスクにも当てはまりません。
より詳しい情報は最新の Large Disk HOWTO を参照してください。

<!--O
<tag/Note 2/ Recently a new boot loader has been written that overcomes
the 1023 sector limit. For more information check out this
<url url="http://www.linuxforum.com/plug/articles/nuni.html"
    name="article">
on nuni.
-->
<tag/注意 2/ 1023 セクタの制限を受けない新しいブートローダが、
最近開発されました。詳細は
<url url="http://www.linuxforum.com/plug/articles/nuni.html"
    name="nuni に関する記事">
を見てください。

</descrip>


<!--O
<sect2>Root
-->
<sect2>ルートファイルシステム
<p>
<nidx>disk!root</nidx>
<descrip>
<!--O
<tag/Speed/ Quite low: only the bare minimum is here, much of
which is only run at startup time.
-->
<tag/速度/
かなり遅くても大丈夫です。
ほんとうに必要最小限のものしかここにはありませんし、
大部分は起動時にしか実行されません。

<!--O
<tag/Size/ Relatively small. However it is a good idea to keep
some essential rescue files and utilities on the root partition and
some keep several kernel versions. Feedback suggests about 20 MB would
be sufficient.
-->
<tag/容量/
比較的小さくて良いでしょう。
しかしシステム修復に必要なファイルやユーティリティ、
バージョンの違ういくつかのカーネルなどを
ルートパーティションに置いておくのも良いアイデアだと思います。
この文書に対するフィードバックをまとめると、
20 MB あれば十分なようです。

<!--O
<tag/Reliability/ High. A failure here will possibly cause a fair bit
of grief and you might end up spending some time rescuing your boot
partition. With some practice you can of course do this in an hour or
so, but I would think if you have some practice doing this you are
also doing something wrong.
-->
<tag/信頼性/
高くなければなりません。このブートパーティションが壊れると、
悲しい思いをする人が多いでしょう。
また復旧にも結構な時間がかかってしまいます。
もちろん練習を積めば 1 時間かそこらで復旧できるようにもなるでしょうが、
復旧の練習を積んでいる人は何か別のヘマもしている人だと私は思います。

<!--O
Naturally you do have a rescue disk? Of course this is updated since
you did your initial installation? There are many ready made rescue
disks as well as rescue disk creation tools you might find valuable.
Presumably investing some time in this saves you from becoming a
root rescue expert.
-->
もちろんレスキューディスクは用意してありますよね。
最初のインストールのときからアップデートしましたか？
世の中には有用なレスキューディスクや、
ディスク作成用のツールが多く存在します。
ルートシステムのレスキューの専門家になるよりも、
これらのツールを探す方が時間を有効に使えるでしょう。

<!--O
<tag/Note 1/ If you have plenty of drives you might consider putting
a spare emergency boot partition on a separate physical drive. It will
cost you a little bit of space but if your setup is huge the time saved,
should something fail, will be well worth the extra space.
-->
<tag/注意 1/
ドライブがたくさんあるのでしたら、
緊急用としてスペアのブートパーティションを
別のドライブに用意しておいても良いかもしれません。
ディスク容量は少々損しますが、セットアップにかかる時間を考えれば、
何かが壊れたときの保険としては充分価値があります。

<!--O
<tag/Note 2/ For simplicity and also in case of emergencies
it is not advisable to put the root partition on a RAID level 0 system.
Also if you use RAID for your boot partition you have to remember to
have the <tt/md/ option turned on for your emergency kernel.
-->
<tag/注意 2/
ルートパーティションを RAID 0 のシステム上に置くのはお勧めできません。
立ち上げ動作が複雑になりますし、障害の際にも問題があります。また、
ブートパーティションに RAID を使う場合は、
レスキュー用カーネルの md 機能を忘れずに有効にしておくことです。

<!--O
<tag/Note 3/ For simplicity it is quite common to keep Boot and Root
on the same partition. If you do that, then
in order to boot from LILO it is important that the
essential boot files reside wholly within cylinder 1023. This includes
the kernel as well as files found in <tt>/boot</tt>.
-->
<tag/注意 3/
システムを単純化するため、
Boot と Root を同じパーティションに配置することは
ごくごく普通に行われています。
このとき LILO からブートするには、
ブートに必要なファイル
(カーネルと <tt>/boot</tt> に置かれているファイル群)
をすべてシリンダ 1023 以下の範囲に収めておくことが大事です。
</descrip>


<!--O
<sect2>DOS etc.
-->
<sect2>DOS など
<p>
<nidx>disk!DOS-related issues</nidx>
<!--O
At the danger of sounding heretical I have included this little section
about something many reading this document have strong feelings about.
Unfortunately many hardware items come with setup and maintenance tools
based around those systems, so here goes.
-->
異教徒と思われたくはないんですが、
読者のみなさんが迫害しているこの手のブツについても
一節を設けることにしました。
残念ながらハードウェアに付いてくる設定ツールには、
この種の OS でしか動かないものがまだ多いんです。
では行きます。

<descrip>
<!--O
<tag/Speed/ Very low. The systems in question are not famed for speed
so there is little point in using prime quality drives. Multitasking or
multi-threading are not available so the command queueing facility found
in SCSI drives will not be taken advantage of. If you have an old IDE
drive it should be good enough. The exception is to some degree Win95
and more notably NT which have multi-threading support which should
theoretically be able to take advantage of the more advanced features
offered by SCSI devices.
-->
<tag/速度/
非常に遅くて良いでしょう。
これらのシステムに対して「高速だ」という評判は聞いたことがありませんから、
ここに高性能のドライブをあてがう価値はほとんどありません。
マルチタスクでもマルチスレッドでもありませんから、
SCSI ドライブのコマンドキューの機能を有利に働かせることもできません。
古い IDE のディスクがあればそれで充分でしょう。
Win95 や NT のカーネルは一応マルチスレッドをサポートしているようですので、
理論的には高機能な SCSI デバイスを有効に使える可能性もあります。

<!--O
<tag/Size/ The company behind these operating systems
is not famed for writing tight
code so you have to be prepared to spend a few tens of MB depending on
what version you install of the OS or Windows. With an old version of
DOS or Windows you might fit it all in on 50 MB.
-->
<tag/容量/
これらの OS を作っているメーカには
「コードが小さい」という評判は特に無いようですから、
インストールする OS や Windows のバージョンにもよりますが、
数 10 MB 程度を用意しておく必要があるでしょう。古いバージョンの
DOS や Windows なら 50 MB あればたいていのものは詰め込めるでしょう。

<!--O
<tag/Reliability/ Ha-ha. As the chain is no stronger than the weakest link
you can use any old drive. Since the OS is more likely to scramble itself
than the drive is likely to self destruct you will soon learn the
importance of keeping backups here.
-->
<tag/信頼性/
はは。「鎖の強さは最も弱い環で決まる」という言葉を聞いたことがありますか？
どんな古いドライブでも構わないでしょう。
ドライブが壊れる前に OS が飛んでしまいますから。
きっと誰もがこのパーティションからバックアップの重要さを学ぶでしょう。

<!--O
Put another way: "<it/Your mission, should you choose to accept it,
is to keep this partition working. The warranty will self destruct
in 10 seconds.../"
-->
別の言葉で言いましょうか。
「<it/君の任務はこのパーティションを稼動させ続けることだ。
なおこのメッセージは 10 秒以内に自動的に消滅する.../」

<!--O
Recently I was asked to justify my claims here. First of all I am not
calling DOS and Windows sorry excuses for operating systems. Secondly
there are various legal issues to be taken into account. Saying there
is a connection between the last two sentences are merely the ravings of the
paranoid. Surely. Instead I shall offer the esteemed reader a few
key words: DOS 4.0, DOS 6.x and various drive compression tools that
shall remain nameless.
-->
最近、これらの主張の正当性を示せと言われました。
でもちょっと待って下さい。
まず私は DOS や Windows のことを、
OS のひどいマガイモノだと言っているわけではありません。
法律的な問題も色々と考えなければなりません。
あー、このいまの 2 文の間に関係があると言うのは偏執者の戯言です。
本当ですって。
えー、では代わりに尊敬すべき読者の皆さんに
いくつかのキーワードを差し上げましょう。
DOS 4.0、DOS 6.x、名もないままに消え去ったたくさんのドライブ圧縮ツール...

</descrip>


<!--O
<sect1>Explanation of Terms
-->
<sect1>用語の説明
<p>
<nidx>disk!terms explained</nidx>
<!--O
Naturally the faster the better but often the happy installer of Linux
has several disks of varying speed and reliability so even though this
document describes performance as 'fast' and 'slow' it is just a rough
guide since no finer granularity is feasible. Even so there are a few
details that should be kept in mind:
-->
もちろんディスクは速いに越したことはありません。
しかし Linux のインストールに当たっては、
様々なスピードや信頼性のディスクが混在することが珍しくありません。
この文書では性能を「速い」とか「遅い」とか言っていますが、
これは粗っぽい分け方に過ぎません。これ以上細かく区別するのは難しいんです。
それでも心に止めておくと良い点はいくつかあります。

<!--O
<sect2>Speed <label id="speed">
-->
<sect2>速度<label id="speed">
<p>
<nidx>disk!terms explained!speed</nidx>
<!--O
This is really a rather woolly mix of several terms: CPU load,
transfer setup overhead, disk seek time and transfer rate. It is in
the very nature of tuning that there is no fixed optimum, and in most
cases price is the dictating factor. CPU load is only significant for
IDE systems where the CPU does the transfer itself
but is generally low for SCSI, see SCSI documentation
for actual numbers. Disk seek time is also small, usually in the
millisecond range. This however is not a problem if you use command
queueing on SCSI where you then overlap commands keeping the bus busy
all the time. News spools are a special case consisting of a huge
number of normally small files so in this case seek time can become
more significant.
-->
実際には「速度」というのはいくつかの要素が複雑に絡み合って決まっています。
例えば CPU 負荷、転送前のオーバーヘッド、ディスクのシーク時間、
転送速度などです。
確立した最適なチューニングというものはありません。
たいていの場合は価格が最も重要な要素になるでしょう。
CPU 負荷は IDE システム以外ではそれほど問題になりません。
IDE システムでは CPU が転送に関与しますが、
SCSI では CPU 負荷は一般に小さいです。
実際の数値に関しては SCSI についての文書を見てください。
ディスクのシーク時間は小さいほうが良く、通常数ミリ秒程度が望ましいでしょう。
SCSI のコマンドキューが使える場合には、
コマンドを重ね送りしてバスを常に有効にできるので、
シーク時間はそれほど問題にはならないでしょう。
ニューススプールのように小さなファイルを大量に含んでいるような特殊な場合には、
シーク時間は重要になるでしょう。

<!--O
There are two main parameters that are of interest here:
-->
ここでは、二つの主要なパラメータについてもう少し述べます。

<descrip>
<!--O
<tag/Seek/ is usually specified in the average time take for the
read/write head to seek from one track to another. This parameter
is important when dealing with a large number of small files such
as found in spool files.
There is also the extra seek delay before the desired sector rotates
into position under the head. This delay is dependent on the angular
velocity of the drive which is why this parameter quite often is
quoted for a drive. Common values are 4500, 5400 and 7200 RPM (rotations
per minute). Higher RPM reduces the seek time but at a substantial cost.
Also drives working at 7200 RPM have been known to be noisy and to
generate a lot of heat, a factor that should be kept in mind if you
are building a large array or "disk farm". Very recently drives working
at 10000 RPM has entered the market and here the cooling requirements
are even stricter and minimum figures for air flow are given.
-->
<tag/シーク時間/
これはディスクの読み書きに際して、
ヘッドがあるトラックから別のトラックへ移動するのにかかる平均時間のことです。
このパラメータは数多くの小さなファイルを扱うような場合に重要になります。
スプール領域などが該当します。
また指定されたセクタがヘッドの位置に回転してくるまでに消費される遅れ時間も
シーク時間に含まれます。この遅れはドライブの回転速度に依存し、
回転速度がドライブの主要なパラメータとみなされている理由の一つになっています。
通常用いられる値は 4500, 5400, 7200 RPM
(rotation per minute: 一分あたりの回転数) です。
回転数が高いものはシークが早くなりますが、高価になります。
また 7200 RPM 動作するドライブは騒音や発熱量が大きくなりがちです。
この事は巨大なディスクアレイやディスクファームを作るときには
気に留めておく必要があるでしょう。
つい最近には 10000 RPM で動作するドライブも市場に出てきました。
この製品では冷却条件が特に厳しくなっており、
エアーフローに関する条件が動作保証に必要になりました。

<!--O
<tag/Transfer/ is usually specified in megabytes per second.
This parameter is important when handling large files that
have to be transferred. Library files, dictionaries and image files
are examples of this. Drives featuring a high rotation speed also
normally have fast transfers as transfer speed is proportional to
angular velocity for the same sector density.
-->
<tag/転送速度/
通常 MB/s という単位で記されます。
このパラメータは大きなファイルを扱う場合に重要になります。
ライブラリのファイルや、辞書・画像ファイルなどがこれに当たります。
回転数の高いドライブでは転送速度も回転速度に比例して大きくなります
(セクタ密度が一定の場合)。
</descrip>

<!--O
It is therefore important to read the specifications for the drives
very carefully, and note that the maximum transfer speed quite often
is quoted for transfers out of the on board cache (burst speed)
and <em>not</em>
directly from the platter (sustained speed).
See also section on
<ref id="power-heating" name="Power and Heating">.
-->
以上からわかるように、ドライブの性能表を注意深く読むことは重要です。
またスペック中の最大転送速度は、
オンボードキャッシュからの転送速度で与えられていることが多く、
必ずしもディスクから直接転送するときの速度ではないことに注意してください。
<ref id="power-heating" name="電力と発熱">
の節も見ておくようにしてください。


<!--O
<sect2>Reliability
-->
<sect2>信頼性
<p>
<nidx>disk!terms explained!reliability</nidx>
<!--O
Naturally no-one would want low reliability disks but one might be
better off regarding old disks as unreliable. Also for RAID purposes
(See the relevant information) it is suggested to use a mixed set of disks
so that simultaneous disk crashes become less likely.
-->
わざわざ低い信頼性のディスクを欲しがる人もいないでしょうが、
古いディスクは信頼性が低いと思っておくほうが良いでしょう。
ところで RAID の用途には、
いろいろな種類のディスクを混ぜて使うのが良いとされています
(関連する文書を見てください)。
そうしておけば、ディスクの同時クラッシュが避けやすくなるからです。

<!--O
So far I have had only one report of total file system failure but
here unstable hardware seemed to be the cause of the problems.
-->
今のところ、ファイルシステム全体が故障したという報告は
私は一つしか聞いたことがありません。
しかし不安定なハードウェアは数多くの障害の原因になるようです。

<!--O
Disks are cheap these days yet people still underestimate the
value of the contents of the drives. If you need higher reliability
make sure you replace old drives and keep spares. It is not unusual
that drives can work more or less continuous for years and years but
what often kills a drive in the end is power cycling.
-->
最近では随分ディスクは安くなりましたが、
人々はまだドライブの中身の重要性を過小評価しているようです。
より高い信頼性が必要なら、
古いドライブは置き換えて、古い方はスペアとして保存しておきましょう。
ドライブが何年にもわたって連続運転を続けることは
特に珍しくはありませんが、
結局最後にドライブを壊してしまうのは電源の on off であることが多いようです。

<!--O
<sect2>Files
-->
<sect2>ファイル
<p>
<nidx>disk!terms explained!files</nidx>
<!--O
The average file size is important in order to decide the most
suitable drive parameters. A large number of small files makes the
average seek time important whereas for big files the transfer speed
is more important.  The command queueing in SCSI devices is very
handy for handling large numbers of small files, but for transfer EIDE
is not too far behind SCSI and normally much cheaper than SCSI.
-->
ファイルの大きさの平均値は、
ドライブのパラメータを選択・決定するときに重要な意味を持ちます。
たくさんの小さなファイルを扱うときはシーク時間が、
大きなファイルを扱うときは転送速度が重要になります。
多数の小さなファイルを扱う場合は
SCSI のコマンドキュ−が有利に働きますが、
転送速度に関しては安い IDE のディスクも
SCSI にそれほどひけをとりません。


<!--O
<sect>File Systems
-->
<sect>いろいろなファイルシステム
<p>
<nidx>disk!file systems</nidx>
<!--O
Over time the requirements for file systems have increased and the
demands for large structures, large files, long file names and more
has prompted ever more advanced file systems, the system that
accesses and organises the data on mass storage.
Today there is a large number of file systems to choose from and this
section will describe these in detail.
-->
歴史とともにファイルシステムへの要請は増えつづけてきました。
大きな構造、大きなファイル、長いファイル名などなどに対する要求から、
ファイルシステムはどんどん進化し、
巨大な記憶装置へのアクセスしたり、
そのような装置を管理したりできるようになっていきました。
今日では数多くのファイルシステムを選択できるようになりました。
この章では、それらファイルシステムについて詳細に述べたいと思います。

<!--O
The emphasis is on Linux but with more input I will be happy to add
information for a wider audience.
-->
今のところ重点は Linux にありますが、より広範な読者向けの情報も、
お寄せいただければ喜んで追加したいと思います。

<!--O
<sect1>General Purpose File Systems
-->
<sect1>汎用のファイルシステム
<p>
<!--O
Most operating systems usually have a general purpose file system for
every day use for most kinds of files, reflecting available features
in the OS such as permission flags, protection and recovery.
-->
ほとんどの OS には汎用のファイルシステムがあり、
これが大抵のファイルに対して常用されています。
このようなファイルシステムは許可属性フラグや保護・復旧など
OS の機能を反映したものになっています。


<sect2><tt/minix/
<p>
<nidx>disk!file system!minix</nidx>
<!--O
This was the original fs for Linux, back in the days Linux was hosted
on minix machines. It is simple but limited in features and hardly ever
used these days other than in some rescue disks as it is rather compact.
-->
これは Linux が最初に用いたファイルシステムでした。
Linux がまだ minix マシンに寄生していた頃のことです。
これは単純ですが機能に制限が多いので、
今日ではレスキューディスクなどを除いてはほとんど用いられていません
 (レスキューディスクに用いられるのはシステムが小さいからです)。

<!--O
<sect2><tt/xiafs/ and <tt/extfs/
-->
<sect2><tt/xiafs/ と <tt/extfs/
<p>
<nidx>disk!file system!xiafs</nidx>
<nidx>disk!file system!extfs</nidx>
<!--O
These are also old and have fallen in disuse and are no longer recommended.
-->
これらも古く、使われなくなってしまいました。
今後はお薦めできません。

<sect2><tt/ext2fs/
<p>
<nidx>disk!file system!ext2fs</nidx>
<!--O
This is the established standard for general purpose in the Linux world.
It is fast, efficient and mature and is under continuous development and
features such as ACL and transparent compression are on the horizon.
-->
Linux の世界で汎用ファイルシステムの標準の地位を確立している
ファイルシステムです。
<tt/ext2fs/ は高速で、効率が良く、成熟したシステムです。
開発もまだ継続しており、
ACL や透過圧縮機能などがそろそろ姿を現しつつあります。

<!--O
For more information check the
<url url="http://web.mit.edu/tytso/www/linux/ext2.html"
    name="ext2fs">
home page.
-->
より詳しい情報は、
<url url="http://web.mit.edu/tytso/www/linux/ext2.html"
    name="ext2fs ホームページ">
を見てください。

<sect2><tt/ext3fs/
<p>
<nidx>disk!file system!ext3fs</nidx>
<!--O
This is the name for the upcoming successor to <tt/ext2fs/ due to enter
stable kernel in the near future. Many features will be added to
<tt/ext2fs/ but to avoid confusion over the name after such a radical
upgrade the name will be changed too. You may have heard of it already
but source code is now in beta relsease . <!-\-not yet available. -\->
-->
これは今後 <tt/ext2fs/ を継承するもので、
近い将来に安定版カーネルに取り込まれます。
このために名前も変更されました。
<tt/ext2fs/ に対して多くの機能が追加されますが、
このような過激なアップグレードの前後で
同じ名前でありつづけるのは混乱の原因となるからです。
既に聞いたことのあるひとは多いでしょうが、
ソースコードはまだβリリースの段階です。

<!--O
Patches are available at
<url url="ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs"
    name="Linux.org">.
-->
パッチは
<url url="ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs"
    name="Linux.org">
から入手できます。


<sect2><tt/ufs/
<p>
<nidx>disk!file system!ufs</nidx>
<!--O
This is the fs used by BSD and variants thereof. It is mature but also
developed for older types of disk drives where geometries were known. The
fs uses a number of tricks to optimise performance but as disk geometries
are translated in a number of ways the net effect is no longer so optimal.
-->
これは BSD やその派生システムで用いられているファイルシステムです。
成熟したシステムですが、
古いタイプのディスクドライブ向けに開発されたもので、
ジオメトリが分かっていなければ使えません。
このファイルシステムは性能を最適化するために多くのトリックを使っていますが、
ディスクジオメトリの変換方法がいくつもあるため、
実際の効果はそれほど大きなものではありません。

<sect2><tt/efs/
<p>
<nidx>disk!file system!efs</nidx>
<!--O
The Extent File System (efs) is Silicon Graphics' early file system
widely used on IRIX before version 6.0 after which xfs has taken over.
While migration to xfs is encouraged efs is still supported
and much used on CDs.
-->
Extent File System (efs) は Silicon Graphics 社の初期のファイルシステムで、
6.0 以前の IRIX で広く使われていました
(それ以降は xfs が使われるようになりました)。
xfs への移行がお薦めですが、 efs もまだサポートされていますし
CD では多く使われています。

<!--O
There is a Linux driver available in early beta stage, available at
<url url="http://aeschi.ch.eu.org/efs/"
    name="Linux extent file system">
home page.
-->
ベータ版になったばかりですが、 Linux のドライバも
<url url="http://aeschi.ch.eu.org/efs/"
    name="Linux extent file system ホームページ">
から入手できます。

<sect2><tt/XFS/
<p>
<nidx>disk!file system!XFS</nidx>
<!--O
<url url="http://www.sgi.com/"
    name="Silicon Graphics Inc (sgi)">
has started porting its mainframe grade file system to Linux.
Source is not yet available as they are busily cleaning out
legal encumberance but once that is done they will provide the
source code under GPL.
-->
<url url="http://www.sgi.com/"
    name="Silicon Graphics Inc (sgi)">
は、彼らのメインフレームグレードのファイルシステムを、
Linux へ移植し始めました。
現在彼らは法律的な厄介ごとを急ピッチで整理している
段階なので、ソースはまだ入手できませんが、これが片づけば
ソースコードは GPL のもとに提供される予定です。

<!--O
More information is already available on the
<!-\- <url url="http://www.sgi.com/projects/xfs/" 000502 -\->
<url url="http://oss.sgi.com/projects/xfs/"
    name="XFS project page">
at SGI.
-->
現在入手できる情報は、 SGI の
<url url="http://oss.sgi.com/projects/xfs/"
    name="XFS project page">
からどうぞ。

<sect2><tt/reiserfs/
<p>
<nidx>disk!file system!reiserfs</nidx>
<nidx>disk!file system!tree based</nidx>
<!--O
As of July, 23th 1997
Hans Reiser <tt/reiser (at) RICOCHET.NET/
has put up the source to his tree based
<!-\- <url url="http://idiom.com/&tilde;beverly/reiserfs.html"  990919 -\->
<!-\- <url url="http://devlinux.com/namesys/" 000501 -\->
<!-\- <url url="http://devlinux.com/projects/reiserfs/" 001203 -\->
<url url="http://devlinux.com/namesys/"
    name="reiserfs">
on the web. While his filesystem has some very interesting features and
is much faster than <tt/ext2fs/ and is in use by a number of people.
Hopefully it will be ready for kernel 2.4.0 which might be ready at
the end of the year.
-->
1997 年 6 月 23 日、
Hans Reiser <tt/reiser (at) RICOCHET.NET/
は、彼が開発したツリーベースのファイルシステムである
<url url="http://www.namesys.com"
    name="reiserfs">
のソースコードを web に置きました。
このファイルシステムには非常に面白い機能がいくつかあるうえ
<tt/ext2fs/ よりもずっと高速であるため、多くの人々が
利用するようになりました。おそらくは今年の年末にリリースされる
2.4.0 カーネルでは利用できるようになるでしょう。


<!-- it is still very experimental and
difficult to integrate with the standard kernel. Expect some
interesting developments in the future - this is different from your
"average log based file system for Linux" project, because Hans
already has working code. -->

<sect2><tt/enh-fs/
<p>
<nidx>disk!file system!enhanced fs</nidx>
<!-- removed 990919
Currently in alpha stage the
<url url="http://www.coker.com.au/&tilde;russell/enh-fs.html"
    name="Enhanced File System">
project aims to combine
file system and volume management into a single layer.
-->
<!--O
The Enhanced File System project is now dead.
-->
Enhanced File System プロジェクトは現在活動していません。

<sect2><tt/Tux2 fs/
<p>
<nidx>disk!file system!Tux2 fs</nidx>
<!--O
This is a variation on the <tt/ext2fs/ that adds robustness
in case of unexpected interruptions such as power failure.
After such an event <tt/Tux2 fs/ will restart with the file system
in a consistent, recently recorded state without fsck or
other recovery operations. To achieve this <tt/Tux2 fs/ uses
a newly designed algorithm called Phase Tree.
-->
これは <tt/ext2fs/ のバリエーションで、
電力障害などの突然の割り込みにおける堅牢性を追加するものです。
このようなイベントの後には、
<tt/Tux2 fs/ は最近記録された整合性のとれている状態で再起動し、
fsck や他のリカバリ動作を行いません。
これを行うために、
<tt/Tux2 fs/ は新たに設計された
Phase ツリーと呼ばれるアルゴリズムを用いています。

<!--O
More information can be found at the
<url url="http://tux2.sourceforge.net"
    name="project home page">.
-->
より詳しい情報は
<url url="http://tux2.sourceforge.net"
    name="プロジェクトのホームページ">
にあります。

<!--O
<sect1>Microsoft File Systems
-->
<sect1>Microsoft のファイルシステム
<p>
<nidx>disk!file system!Microsoft</nidx>
<nidx>disk!file system!confusion</nidx>
<!--O
This company is responsible for a lot, including a number of filesystems
that has at the very least caused confusions.
-->
この会社は多くのことに責任がありますが、
多くのファイルシステムを作り、それによって
(一番穏やかな言い方でも) 混乱を引き起こしたこともそのひとつです。

<sect2><tt/fat/
<p>
<nidx>disk!file system!fat</nidx>
<!--O
Actually there are 2 <tt/fat/s out there, <tt/fat12/ and <tt/fat16/
depending on the partition size used but fortunately the difference
is so minor that the whole issue is transparent.
-->
じつは <tt/fat/ には二種類あります。 <tt/fat12/ と <tt/fat16/
で、利用しているパーティションサイズに依存しています。
しかしこれらの違いはごくわずかですから、
幸運なら全く違いに気付かずにすむかもしれません。

<!--O
On the plus side these are fast and simple and most OSes understands
it and can both read and write this fs. And that is about it.
-->
長所としては、これらは速く、簡単で、
多くの OS から読み書きアクセスができます。
というかそのためだけのものですね。

<!--O
The minus side is limited safety, severely limited permission flags
and atrocious scalability. For instance with <tt/fat/ you cannot
have partitions larger than 2 GB.
-->
欠点としては、安全性が低い、許可属性フラグが非常に少ない、
拡張性が最悪に乏しい、などが挙げられます。
例えば <tt/fat/ では 2 GB 以上のパーティションを扱うことができません。

<sect2><tt/fat32/
<p>
<nidx>disk!file system!fat32</nidx>
<!--O
After about 10 years Microsoft realised <tt/fat/ was about, well, 10 years
behind the times and created this fs which scales reasonably well.
-->
およそ 10 年たって、 Microsoft は <tt/fat/ の問題に気付きました。
そして、あー、10 年時代を遡って、このファイルシステムを作りました。
拡張性はまあまあですけどね。

<!--O
Permission flags are still limited.
NT 4.0 cannot read this file system but Linux can.
-->
許可属性フラグは少ないままです。
NT 4.0 はこのファイルシステムを読むことができません。
Linux はできます。

<sect2><tt/vfat/
<p>
<nidx>disk!file system!vfat</nidx>
<!--O
At the same time as Microsoft launched <tt/fat32/ they also added
support for long file names, known as <tt/vfat/.
-->
Microsoft は <tt/fat32/ を公開すると同時に、
長いファイル名のサポートを追加しました。
これが <tt/vfat/ です。

<!--O
Linux reads <tt/vfat/ and <tt/fat32/ partitions by mounting with
type <tt/vfat/.
-->
<tt/vfat/ タイプでマウントすれば、
Linux は <tt/vfat/ と <tt/fat32/ のパーティションを
読むことができます。

<sect2><tt/ntfs/
<p>
<nidx>disk!file system!ntfs</nidx>
<!--O
This is the native fs of Win-NT but as complete information is not available
there is limited support for other OSes.
-->
これは Win-NT のネイティブなファイルシステムです。
しかし完全な情報が公開されていないために、
他の OS ではほとんどサポートされていません。

<!--O
<sect1>Logging and Journaling File Systems
-->
<sect1>Logging ファイルシステム・ Journaling ファイルシステム
<p>
<nidx>disk!file system!logging file systems</nidx>
<nidx>disk!file system!journaling file systems</nidx>
<!--O
These take a radically different approach to file updates by
logging modifications for files in a log and later at some
time checkpointing the logs.
-->
これらは従来とは根本的に異なった方法でファイル更新を扱います。
ファイルの更新情報はログに記録しておき、
しばらく後のある時点で、
そのログを checkpointing する
(メインの部分に反映させる) のです。

<!--O
Reading is roughly as fast as traditional file systems that
always update the files directly.
Writing is much faster as only updates are appended to a log.
All this is transparent to the user. It is in reliability and
particularly in checking file system integrity that these
file systems really shine.
Since the data before last checkpointing is known to be good
only the log has to be checked, and this is much faster than
for traditional file systems.
-->
読み出しの性能は、
ファイルを直接更新する従来のファイルシステムとそれほど変わりません。
書き込みはずっと高速です。更新はログに追加されるだけだからです。
ユーザに対するインターフェースはこれまでと変わりません。
このファイルシステムは信頼性に優れ、
またファイルシステムの整合性チェックが非常に有利になっています。
最後に checkpointing を行った以前から存在するデータは正しいとみなせますから、
ログだけをチェックすれば良いわけです。
したがって従来のファイルシステムよりもずっと高速になるのです。

<!--O
Note that while
<em/logging/ filesystems keep track of changes made to both data and inodes,
<em/journaling/ filesystems keep track only of inode changes.
-->
<em/logging/ ファイルシステムはデータと inode の両方の変更を記録します。
一方 <em/journaling/ ファイルシステムは inode の変更だけを記録します。

<!--O
Linux has quite a choice in such file systems but none are
yet in production quality. Some are also on hold.
-->
Linux ではこのようなファイルシステムに対する選択肢はたくさんありますが、
いずれも製品としてのクォリティは持っていません。
開発が止まっているものもあります。

<itemize>
<!--O
<item>Adam Richter from Yggdrasil posted some time ago that they have been
working on a compressed log file based system but that this project is
currently on hold. Nevertheless a non-working version is available on
their FTP server. Check out
<url url="ftp://ftp.yggdrasil.com/private/adam"
    name="the Yggdrasil ftp server">
where special patched versions of the kernel can be found.
-->
<item>Yggdrasil の Adam Richter はちょっと昔に、
圧縮機能を持った log ベースのファイルシステムを開発していることを
ポストしました。しかしこのプロジェクトは現在止まっています。
動作しない段階の版ではありますが、彼らの FTP サーバから入手できます。
<url url="ftp://ftp.yggdrasil.com/private/adam/"
    name="Yggdrasil ftp server">
をチェックすれば、特殊なパッチが当てられたカーネルが見付かるでしょう。

<!--O
<item>Another project is the
<!-\- <url url="http://collective.cpoint.net/lfs/" 000503 -\->
<url url="http://outflux.net/projects/lfs/"
    name="Linux log-structured Filesystem Project">
which sadly also is on hold. Nevertheless this page contains
much information on the topic.
-->
<item>他のプロジェクトとしては、
<url url="http://outflux.net/projects/lfs/"
    name="Linux log-structured Filesystem Project">
があります。これも残念なことに止まっています。
しかしこのページにはこのトピックに関する多くの情報があります。

<!--O
<item>Then there is the
<url url="http://www.complang.tuwien.ac.at/czezatke/lfs.html"
    name="LinLogFS -\- A Log-Structured Filesystem For Linux">
(formerly known as dtfs)
which seems to be going strong. Still in alpha but sufficiently
complete to make programs run off this file system
-->
<item>また
<url url="http://www.complang.tuwien.ac.at/czezatke/lfs.html"
    name="LinLogFS -- A Log-Structured Filesystem For Linux">
(以前は dtfs)
というプロジェクトがあり、強化されつつあるようです。
まだアルファ版ですが、
このファイルシステムからのプログラム起動が高速化される程度にまでは
完成しています。

<!--O
<item>Finally there is the
<url url="http://developer.axis.com/software/jffs/"
    name="Journaling Flash File System">
designed for their embedded diskless systems such as
their Linux based web camera.
-->
<item>最後に
<url url="http://developer.axis.com/software/jffs/"
    name="Journaling Flash File System">
を挙げておきましょう。組み込みのディスクレスシステム向けに設計されたもので、
例えば Linux ベースの web カメラなどに用いられています。
</itemize>

<!--O
Note that <tt/ext3fs/, <tt/XFS/ and <tt/reiserfs/ also have
features for logging or journaling.
-->
<tt/ext3fs/, <tt/XFS/, <tt/reiserfs/
には logging や journaling の機能があることも触れておきます。

<!--O
<sect1>Read-only File Systems
-->
<sect1>リードオンリーのファイルシステム
<p>
<nidx>disk!file system!read-only file systems</nidx>
<!--O
Read-only media has not escaped the ever increasing complexities
seen in more general file systems so again there is a large choice
to choose from with corresponding opportunities for exciting mistakes.
-->
リードオンリーのメディアも
複雑化してきたファイルシステムの例外であることはできませんでした。
したがってこの分野にも多くの選択肢があり、
頭にくるようなミスをしてしまうような可能性もあるわけです。

<!--O
Note that <tt/ext2fs/ works quite well on a CD-ROM
and seems to save space while offering the normal file system features
such as long file names and permissions that can be retained when
copying files across to read-write media. Also having <!-\- <file>/dev</file> -\->
<htmlurl url="file:///dev/"
    name="/dev">
on a CD-ROM is possible.
-->
<tt/ext2fs/ も CD-ROM でちゃんとうまく動作しますし、
領域の節約になるようです。通常のファイルシステムの機能である
長いファイル名や許可属性も提供されますし、これらは
読み書き可能なメディアに対してコピーするときにも保存されます。
CD-ROM に
<htmlurl url="file:///dev/" name="/dev">
をつくることも可能です。

<nidx>disk!file system!CD-ROM</nidx>
<nidx>disk!file system!DVD</nidx>
<nidx>disk!file system!loopback</nidx>
<!--O
Most of these are used with the CD-ROM media but also the new
DVD can be used and you can even use it through the loopback device
on a hard disk file for verifying an image before burning a ROM.
-->
これらの多くは CD-ROM メディアで用いられていますが、
最近の DVD でも使えますし、
ハードディスクファイル上に作成した loopback デバイス
(ROM を焼く前にイメージをチェックするために使います)
でも用いることができます。

<nidx>disk!file system!rom file systems</nidx>
<nidx>disk!file system!romfs</nidx>
<!--O
There is a read-only <tt/romfs/ for Linux but as that is not disk
related nothing more will be said about it here.
-->
Linux にはリードオンリーの <tt/romfs/ もありますが、
これはディスク用のものではありませんので、
ここではこれ以上は触れません。

<sect2><tt/High Sierra/
<p>
<nidx>disk!file system!High Sierra</nidx>
<!--O
This was one of the earliest standards for CD-ROM formats,
supposedly named after the hotel where the final agreement took place.
-->
これは CD-ROM のフォーマットとしては最も初期に標準となったものでした。
おそらく最終的な合意が成されたホテルの名前に基づいて名づけられたのでしょう。

<!--O
<tt/High Sierra/ was so limited in features that new extensions simply
had to appear and while there has been no end to new formats the original
<tt/High Sierra/ remains the common precursor and is therefore still
widely supported.
-->
<tt/High Sierra/ にはごく限られた機能しかなかったので、
新しい拡張がなされていきました。
新しいフォーマットは続々と登場していきましたが、
オリジナルの <tt/High Sierra/ はそれらの共通の母体であり、
したがって現在でも広くサポートされています。

<sect2><tt/iso9660/
<p>
<nidx>disk!file system!iso9660</nidx>
<!--O
The International Standards Organisation made their extensions and
formalised the standard into what we know as the <tt/iso9660/ standard.
-->
International Standard Organization でも拡張とその標準化が行われました。
<tt/iso9660/ 規格として知られているものです。

<!--O
The Linux iso9660 file system supports both High Sierra as well as
<tt/Rock Ridge/ extensions.
-->
Linux の iso9660 ファイルシステムは High Sierra と <tt/Rock Ridge/
拡張を両方サポートしています。

<sect2><tt/Rock Ridge/
<p>
<nidx>disk!file system!Rock Ridge</nidx>
<!--O
Not everyone accepts limits like short filenames and lack of permissions
so very soon the <tt/Rock Ridge/ extensions appeared to rectify these
shortcomings.
-->
短い名前や許可属性がないことに我慢していられる人たちばかりではなかったので、
<tt/Rock Ridge/ 拡張がこれらの欠点を補うべく早々に登場しました。

<sect2><tt/Joliet/
<p>
<nidx>disk!file system!Joliet</nidx>
<!--O
Microsoft, not be be outdone in the standards extension game, decided
it should extend CD-ROM formats with some internationalisation features
and called it <tt/Joliet/.
-->
Microsoft も、標準拡張ゲームから遅れを取らないようにすべく、
CD-ROM フォーマットを拡張して国際化の機能を付加しました。
彼らはこれを <tt/Joliet/ と名づけました。

<!--O
Linux supports this standards in kernels 2.0.34 or newer.
You need to enable NLS in order to use it.
-->
Linux はこの規格を 2.0.34 以降のカーネルでサポートしています。
この機能を用いるには NLS を有効にする必要があります。

<!--O
<sect2>Trivia
-->
<sect2>閑話
<p>
<nidx>disk!file system!Trivia</nidx>
<!--O
Joliet is a city outside Chicago; best known for being the site of
the prison where Jake was locked up in the movie "Blues Brothers."
Rock Ridge (the UNIX extensions to ISO 9660) is named
after the (fictional) town in the movie "Blazing Saddles."
-->
Joliet は Chicago 郊外の町です。映画 "Blues Brothers" で
Jake が収監されていた刑務所があることで知られています。
Rock Ridge (ISO 9660 に対する UNIX 拡張) は、
映画 "Blazing Saddles" に出てくる (架空の) 町にちなんで名づけられました。

<sect2><tt/UDF/
<p>
<nidx>disk!file system!UDF</nidx>
<!--O
With the arrival of DVD with up to about 17 GB of storage capacity
the world seemingly needed another format, this time ambitiously named
Universal Disk Format (UDF).
This is intended to replace <tt/iso9660/ and will be required for DVD.
-->
DVD が 18 GB もの容量とともに登場すると、
世の中にはまた別のフォーマットが必要になりました。
今度は野心的にも Universal Disk Format (UDF) という名前がつけられました。
これは <tt/iso9660/ を置き換えようとするもので、
DVD にはこれが用いられるようになるでしょう。
<!-- takei DVDの容量で18GBと17GBと相違があります．原文からですが． -->

<!--O
Currently this is not in the standard Linux kernel but a project
is underway to make a
<url url="http://trylinux.com/projects/udf/index/htm"
    name="UDF driver">
for Linux. Patches and documentation are available.
-->
現在のところでは標準カーネルではサポートされていません。
しかし Linux 用の
<url url="http://trylinux.com/projects/udf/index/htm"
    name="UDF driver プロジェクト">
が進行中です。パッチと文書とが入手できます。

<!--O
More information is also available at the
<url url="http://atv.ne.mediaone.net/linux-dvd/"
    name="Linux and DVDs">
page.
-->
詳しい情報は
<url url="http://atv.ne.mediaone.net/linux-dvd/"
    name="Linux and DVDs">
のページからどうぞ。

<!-- <url url="http://www.rpi.edu/&tilde;veliaa/linux-dvd" -->


<!--O
<sect1>Networking File Systems
-->
<sect1>ネットワークファイルシステム
<p>
<nidx>disk!file system!networking file systems</nidx>
<!--O
There is a large number of networking technologies available that
lets you distribute disks throughout a local or even global networks.
This is somewhat peripheral to the topic of this HOWTO but as it can
be used with local disks I will cover this briefly. It would be best
if someone (else) took this into a separate HOWTO...
-->
ディスクをローカルな (あるいはグローバルな)
ネットワークに公開することを可能にするような
ネットワーク技術もたくさん存在します。
これはこの HOWTO の目的からするとおまけ的な話題ですが、
まあローカルなディスクと一緒に利用することもできるので、
簡単に網羅しておきます。
でもこれは誰かが別の HOWTO に仕立ててくれるのが一番いいでしょうね...

<sect2><tt/NFS/
<p>
<nidx>disk!file system!NFS</nidx>
<!--O
This is one of the earliest systems that allows mounting a file space
on one machine onto another. There are a number of problems with <tt/NFS/
ranging from performance to security but it has nevertheless become
established.
-->
あるマシンのファイルスペースを他のマシンからマウントさせるための技術として、
もっとも初期からあるものです。
<tt/NFS/ には性能からセキュリティにいたるまで数多くの問題が存在しますが、
しかし確立された技術であることも間違いありません。

<sect2><tt/AFS/
<p>
<nidx>disk!file system!AFS</nidx>
<!--O
This is a system that allows efficient sharing of files
across large networks. Starting out as an academic project
it is now sold by
<url url="http://www.transarc.com"
    name="Transarc">
whose home page gives you more details.
-->
これは大きなネットワークで有効にファイルを共有するためのシステムです。
学術的なプロジェクトとしてスタートしましたが、現在では
<url url="http://www.transarc.com"
    name="Transarc">
によって販売されるようにもなっています。
彼らのホームページから詳細が得られるはずです。

<!--O
Derek Atkins, of MIT, ported AFS to Linux and has also set up the
Linux AFS mailing List (
<htmlurl url="mailto:linux-afs@mit.edu"
        name="linux-afs@mit.edu">)
for this which is open to the public.
Requests to join the list should go to
<htmlurl url="mailto:linux-afs-request@mit.edu"
        name="linux-afs-request@mit.edu">
and finally bug reports should be directed to
<htmlurl url="mailto:linux-afs-bugs@mit.edu"
        name="linux-afs-bugs@mit.edu">.
-->
MIT の Derek Atkins は AFS を Linux に移植し、また
Linux AFS mailing List
<htmlurl url="mailto:linux-afs@mit.edu"
        name="linux-afs@mit.edu">
を準備してくれました。このメーリングリストは公開されています。
メーリングリストへの参加希望は
<htmlurl url="mailto:linux-afs-request@mit.edu"
	name="linux-afs-request@mit.edu">
まで。またバグの報告は
<htmlurl url="mailto:linux-afs-bugs@mit.edu"
	name="linux-afs-bugs@mit.edu">
へ送ってください。

<!--O
Important: as AFS uses encryption it is
restricted software and cannot easily be exported from the US.
-->
重要: AFS は暗号化技術を使っているので、
アメリカ国外への持ち出しは許可されていません。

<!--O
IBM who owns Transarc, has announced the availability of the latest
version of client as well as server for Linux.
-->
Transarc を保有する IBM では、
最新の Linux 向けクライアント・サーバの公開をアナウンスしました。

<!--O
Arla is a free AFS implementation, check the
<url url="http://www.stacken.kth.se/projekt/arla/"
    name="Arla homepage">
for more information as well as documentation.
-->
Arla はフリーな AFS の実装です。
詳しい情報やドキュメントは
<url url="http://www.stacken.kth.se/projekt/arla/"
    name="Arla homepage">
を参照してください。


<sect2>Coda
<p>
<nidx>disk!file system!Coda</nidx>
<!-- Major input from Dr. A V LeBlanc -->
<!-- Work has started on a free replacement of <tt/AFS/ and is called -->
<!--O
A  networking filesystem similar to <tt/AFS/ is underway and is called
<url url="http://coda.cs.cmu.edu/"
    name="Coda">.
This is designed to be more robust and fault tolerant than <tt/AFS/,
and supports mobile, disconnected operations.
Currently it does not scale very well, and does not really have
proper administrative tools, as <tt/AFS/ does and <tt/ARLA/ is
beginning to.
-->
<tt/AFS/ と似たネットワークファイルシステムも準備中で、これは
<url url="http://coda.cs.cmu.edu/"
    name="Coda">
という名前が付いています。
これは <tt/AFS/ より堅牢性・耐障害性に勝るよう設計され、
モバイル動作や、切断動作にも対応しています。
今のところはあまり性能が出ていませんし、
<!--nakano: scale? -->
<tt/AFS/ が備えている (また <tt/ARLA/ が備えはじめている)
管理用の適切なツールがありません。


<sect2><tt/nbd/
<p>
<nidx>disk!file system!nbd</nidx>
<nidx>disk!device!network block device</nidx>
<!--O
The
<url url="http://atrey.karlin.mff.cuni.cz/&tilde;pavel/"
    name="Network Block Device">
(<tt/nbd/) is available in Linux kernel 2.2
and later and offers reportedly excellent performance. The interesting
thing here is that it can be combined with RAID (see later).
-->
<url url="http://atrey.karlin.mff.cuni.cz/&tilde;pavel"
    name="Network Block Device (<tt/nbd/)">
は Linux 2.2 以降で利用でき、非常に優れた性能を持っているそうです。
興味深いことには、
これは RAID (後述) と組み合わせることができるのだそうです。

<sect2><tt/enbd/
<p>
<nidx>disk!file system!enbd</nidx>
<nidx>disk!device!enhanced network block device</nidx>
<!--O
The
<url url="http://www.il.uc3m.es/&tilde;ptb/nbd"
    name="Enhanced Network Block Device">
(<tt/enbd/) is a project to enhance the <tt/nbd/ with
features such as block journaled multi channel communications,
internal failover and automatic balancing between channels
and more.
-->
<url url="http://www.il.uc3m.es/&tilde;ptb/nbd"
    name="Enhanced Network Block Device">
(<tt/enbd/) は <tt/nbd/ を改良しようとしているプロジェクトで、
block 単位でジャーナルされたマルチチャネル通信・
<!--nakano: block journaled multi channel communications?-->
内部フェイルオーバー・チャネル間の自動負荷分散などの機能を
導入しようとしています。

<!--O
The intended use is for RAID over the net.
-->
想定されていた利用法は、ネット越しの RAID 用途です。

<sect2>GFS
<p>
<nidx>disk!file system!GFS</nidx>
<nidx>disk!device!Global File System</nidx>
<!--O
The
<url url="http://gfs.lcse.umn.edu/"
    name="Global File System">
is a new file system designed for storage across a wide area network.
It is currently in the early stages and more information will come
later.
-->
<url url="http://gfs.lcse.umn.edu/"
    name="Global File System">
はワイドエリアネットワークでのストレージを目的として設計された
新しいファイルシステムです。現在はまだ初期段階で、
より詳しい情報がまた登場するでしょう。


<!--O
<sect1>Special File Systems
-->
<sect1>特殊なファイルシステム
<p>
<!--O
In addition to the general file systems there is also a number of
more specific ones, usually to provide higher performance or other
features, usually with a tradeoff in other respects.
-->
一般的なファイルシステムに加え、より特殊なシステムも多数存在します。
より高い性能や、様々な機能を提供します
(通常は他の点とのトレードオフによってですが)。

<!--O
<sect2><tt/tmpfs/ and <tt/swapfs/ <label id="tmpfs">
-->
<sect2><tt/tmpfs/ と <tt/swapfs/ <label id="tmpfs">
<p>
<nidx>disk!file system!tmpfs</nidx>
<nidx>disk!file system!swapfs</nidx>
<!--O
For short term fast file storage SunOS offers <tt/tmpfs/ which is
about the same as the <tt/swapfs/ on NeXT.
This overcomes the inherent slowness in <tt/ufs/ by caching file data
and keeping control information in memory. This means that data on such
a file system will be lost when rebooting and is therefore mainly
suitable for <tt>/tmp</tt> area but not <tt>/var/tmp</tt> which is where
temporary data that must survive a reboot, is placed.
-->
一時的に利用するための高速なファイルストレージとして、
SunOS では <tt/tmpfs/ というものが提供されています。
NeXT の <tt/swapfs/ もほぼ同様のものです。
これは <tt/ufs/ に宿命的に存在していた速度の遅さを克服するもので、
ファイルデータのキャッシュとコントロール情報をメモリに置くものです。
したがってこのようなファイルシステム上にあるデータは
再起動時には失われます。
ですから主に <tt>/tmp</tt> 領域に向いています。
<tt>/var/tmp</tt> のデータは再起動したときにも残っている必要がありますから、
こちらには使ってはいけません。

<!--O
SunOS offers very limited tuning for <tt/tmpfs/ and the number of
files is even limited by total physical memory of the machine.
-->
SunOS では <tt/tmpfs/ に対するチューニングはほとんど行うことができません。
また総ファイル数はマシンの物理メモリによって制限されます。

<!--O
Linux does not have an equivalent to such file system and it is felt
by many that <tt/ext2fs/ is fast enough to eliminate the need.
-->
Linux には同等なファイルシステムは存在しません。
多くの人は <tt/ext2fs/ は十分高速だと思っているので、
そのようなニーズが存在しないのでしょう。


<sect2><tt/userfs/
<p>
<nidx>disk!file system!userfs</nidx>
<nidx>disk!file system!arcfs</nidx>
<nidx>disk!file system!docfs</nidx>
<!--O
The user file system (<tt/userfs/) allows a number of extensions to
traditional file system use such as
FTP based file system, compression (<tt/arcfs/) and fast prototyping
and many other features. The <tt/docfs/ is based on this filesystem.
Check the
<url url="http://www.goop.org/&tilde;jeremy/userfs/"
    name="userfs homepage">
for more information.
-->
user file system (<tt/userfs/) は
従来のファイルシステムに様々な機能追加を可能にするものです。
例えば FTP ベースのファイルシステムや
圧縮機能 (<tt/arcfs/)、
高速な prototyping、
他にもいろいろなものがあります。
詳しい情報は
<url url="http://www.goop.org/&tilde;jeremy/userfs/"
    name="userfs homepage">
をチェックしてください。


<sect2><tt/devfs/
<p>
<nidx>disk!file system!devfs</nidx>
<!--O
When disks are added, removed or just fail it is likely that
disk device names of the remaining disks will change.
For instance if <tt/sdb/ fails then the old <tt/sdc/ becomes <tt/sdb/,
the old <tt/sdc/ becomes <tt/sdb/ and so on.
Note that in this case <tt/hda/, <tt/hdb/ etc will remain unchanged.
Likewise if a new drive is added the reverse may happen.
-->
ディスクが追加されたり削除されたり故障したりすると、
残りのディスクのディスクデバイス名が変更されてしまうことが良く起こります。
例えば <tt/sdb/ が故障すると、
<tt/sdc/ だったものが <tt/sda/ になり、
<tt/sda/ だったものが <tt/sdc/ になってしまったりします。
なお <tt/hda/ の場合には、 <tt/hdb/ などは変化しません。
同様に追加の際にも変化は起きません。

<!--O
There is no guarantee that SCSI ID 0 becomes <tt/sda/ and that adding
disks in increasing ID order will just add a new device name without
renaming previous entries, as some SCSI drivers assign from ID 0 and up
while others reverse the scanning order.
Likewise adding a SCSI host adapter can also cause renaming.
-->
SCSI ID 0 が <tt/sda/ になるという保証はありません。
ですからディスクを大きな ID 番号に順に追加しても、
以前からのデバイス名が保存されたまま
新しいデバイス名で追加されるとは限りません。
SCSI のドライバには、 ID 0 から小さい順に割り当てを行うものと、
検索された順に割り当てを行うものが共存しているからです。
同様に SCSI ホストアダプタの追加の際にも
名前の変更が起こる可能性があります。

<!--O
Generally device names are assigned in the order they are found.
-->
一般には、デバイス名は見付かった順に割り当てられます。

<!--O
The source of the problem lies in the limited number of bits available
for major and minor numbering in the device files used to describe the
device itself. You an see these in the <!-\- <file>/dev</file> -\->
<htmlurl url="file:///dev/"
    name="/dev">
directory, info
on the numbering and allocation can be found in <tt/man MAKEDEV/.
Currently there are 2 solutions to this problem in various stages of
development:
-->
この問題の原因は、デバイスファイルに対する
メジャー番号・マイナー番号に用いることのできるビット桁数が
制限されていることにあります。
これらは
<htmlurl url="file:///dev/"
    name="/dev">
ディレクトリに存在し、
番号づけと割り当ての情報は <tt/man MAKEDEV/ から得られます。
現在のところ、この問題解決には 2 つのアプローチが取られており、
それぞれ異なる開発段階にあります。

<descrip>
<!--O
<tag/scsidev/ works by creating a database of drives and where they
belong, check <em/ man scsifs/ and the
<htmlurl url="http://www.garloff.de/kurt/linux/scsidev/"
    name="scsidev home page">
for more information
-->
<tag/scsidev/
これはドライブとそれらの位置に関する情報のデータベースを作成して動作します。
詳しい情報は <tt/man scsifs/ や
<htmlurl url="http://www.garloff.de/kurt/linux/scsidev/"
    name="scsidev home page">
をチェックしましょう。

<!--O
<tag/devfs/ is a more long term project aimed at getting around the
whole business of device numbering by making the <!-\- <file>/dev</file> -\->
<htmlurl url="file:///dev/"
    name="/dev">
directory a kernel file system in the same way as <!-\- <file>/procfs</file> -\->
<htmlurl url="file:///proc/"
    name="/proc">
is.
More information will appear as it becomes available.
-->
<tag/devfs/
これはもう少し長期的展望に立ったプロジェクトで、
デバイスの番号づけそのものを止め、
<htmlurl url="file:///proc/"
    name="/proc">
のような動作をするカーネルファイルシステムとして
<htmlurl url="file:///dev/"
    name="/dev">
ディレクトリを使おう、というものです。
より詳しい情報が入手できるようになったら、今後この文書に追加します。
</descrip>


<sect2><tt/smugfs/
<p>
<nidx>disk!file system!smugfs</nidx>
<nidx>disk!file system!huge files</nidx>
<!--O
For a number of reasons it is currently difficult to have files
bigger than 2 GB. One file system that tries to overcome this
limit is <tt/smugfs/ which is very fast but also simple. For instance
there are no directories and the block allocation is simple.
-->
色々な理由から、 2 GB 以上の大きさのファイルを作ることは
現在では困難です。この制限を乗り越えようと試みている
ファイルシステムの一つが <tt/smugfs/ です。これは非常に高速で
シンプルなものです。たとえばディレクトリはありませんし、
ブロック割り当ても単純です。

<!--O
It is available as
<!-\- http://atrey.karlin.mff.cuni.cz/pub/local/mj/linux/smugfs-0.0.tar.gz -\->
<url url="ftp://atrey.karlin.mff.cuni.cz/pub/local/mj/linux/"
    name="compressed tarred source code">
and while it worked with kernel version 2.1.85 it is quite possible some
work is required to make it fit into newer kernels. Also the low version
number (0.0) suggests extra care is required.
-->
圧縮された tar 形式で
<url url="ftp://atrey.karlin.mff.cuni.cz/pub/local/mj/linux/"
    name="ソースコード">
が入手できます。これは 2.1.85 版のカーネル用のものですが、
多少作業をすれば最近のカーネルに対応させることも可能でしょう。
バージョン番号が小さい (0.0) ことから、取り扱いには極めて
注意が必要かと思われます。


<!--O
<sect1>File System Recommendations
-->
<sect1>ファイルシステムのお勧め
<p>
<!--O
There is a jungle of choices but generally it is recommended to
use the general file system that comes with your distribution.
If you use <tt/ufs/ and have some kind of <tt/tmpfs/ available
you should first start off with the general file system to get
an idea of the space requirements and if necessary buy more
RAM to support the size of <tt/tmpfs/ you need. Otherwise you
will end up with mysterious crashes and lost time.
-->
まさに選択肢のジャングルですが、
通常はディストリビューションで提供されている
汎用のファイルシステムを用いるのが良いでしょう。
<tt/ufs/ を使うとき、 <tt/tmpfs/ のようなものが同時に利用できる場合は、
まず汎用のファイルシステムからスタートして、
容量がどのくらい必要かを見積もり、
それに応じて <tt/tmpfs/ が必要とする RAM を買い足しましょう。
さもないと原因不明のクラッシュに見舞われ、
時間を無駄にすることになります。

<!--O
If you use dual boot and need to transfer data between the two
OSes one of the simplest ways is to use an appropriately sized
partition formatted with <tt/fat/ as most systems can reliably
read and write this.
Remember the limit of 2 GB for <tt/fat/ partitions.
-->
デュアルブートマシンで、
それぞれの OS でデータを共有する必要がある場合に最も簡単なのは、
適切なサイズのパーティションを
<tt/fat/ でフォーマットすることです。
大抵のシステムはこのファイルシステムを安全に読み書きできるはずですから。
ただし <tt/fat/ パーティションには 2 GB の制限があるのを忘れないように。

<!--O
For more information of file system interconnectivity you can
check out the
<!-\- <url url="http://www.ceid.upatras.gr/&tilde;gef/fs/" 000502 -\->
<url url="http://students.ceid.upatras.gr/&tilde;gef/fs/oldindex.html"
    name="file system">
page
which has been superceded by
<url url="http://www.penguin.cz/&tilde;mhi/fs/"
    name="file system">
and the article
<url url="http://linuxtoday.com/stories/5556.html"
    name="Kragen's Amazing List of Filesystems">.
-->
ファイルシステムの相互可搬性に関する詳細は、
<url url="http://students.ceid.upatras.gr/&tilde;gef/fs/oldindex.html"
    name="file system">
のページをチェックしてください。なおこのページは今後
<url url="http://www.penguin.cz/&tilde;mhi/fs/"
    name="file system">
と
<url url="http://linuxtoday.com/stories/5556.html"
    name="Kragen's Amazing List of Filesystems">
が継承するようです。


<!--O
That guide is being superseded by a HOWTO which is underway and
a link will be added when it is ready.
-->
このガイドは HOWTO にまとめられている最中です。
完成したら、ここからもリンクする予定です。

<!--O
To avoid total havoc with device renaming if a drive fails
check out the scanning order of your system and try to keep
your root system on <tt/hda/ or <tt/sda/ and removable media
such as ZIP drives at the end of the scanning order.
-->
ドライブが故障したときに、
デバイス名の変更によってシステムが災厄に襲われないようにするためには、
システムの検索順序を調べ、ルートファイルシステムを
<tt/hda/ か <tt/sda/ に保つようにし、
ZIP ドライブのようなリムーバブルメディアを検索順の最後に配置しましょう。


<!--O
<sect>Technologies <label id="technologies">
-->
<sect>ディスク関連技術<label id="technologies">
<p>
<nidx>disk!technologies</nidx>
<!--O
In order to decide how to get the most of your devices you need to
know what technologies are available and their implications. As always
there can be some tradeoffs with respect to speed, reliability, power,
flexibility, ease of use and complexity.
-->
手持ちのデバイスを最大限利用するにはどうすればよいかを判断するには、
どんな技術が現在利用可能で、
それらはどのようなものなのかを知る必要があります。
いつものことながら速度や信頼性、能力、柔軟さ、使い易さ、複雑さなどなど、
一長一短があります。

<!--O
Many of the techniques described below can be stacked in a number
of ways to maximise performance and reliability, though at the cost
of added complexity.
-->
以下に記述されている技術を組み合わせる方法も数多くあり、
性能や信頼性を向上させることができます。
ただし複雑になるという代価も当然生じますが。

<sect1>RAID<label id="RAID">
<p>
<nidx>disk!technologies!RAID</nidx>
<!--O
This is a method of increasing reliability, speed or both by using multiple
disks in parallel thereby decreasing access time and increasing transfer
speed. A checksum or mirroring system can be used to increase reliability.
Large servers can take advantage of such a setup but it might be overkill
for a single user system unless you already have a large number of disks
available. See other documents and FAQs for more information.
-->
この方法は、複数のディスクを並列に使うことによって
アクセス時間やデータ転送速度を向上させ、
ディスクシステムの信頼性と速度とを高めようというものです。
チェックサムやミラーリングが信頼性向上の手法として用いられています。
大きなサーバでは有効な方法ですが、
シングルユーザのシステムには過剰な機能でしょう。
既にたくさんのディスクがあるような場合には考慮しても良いかもしれません。
他の文書や FAQ なども見てください。

<!--O
For Linux one can set up a RAID system using either software
(the <tt>md</tt> module in the kernel), a Linux compatible
controller card (PCI-to-SCSI) or a SCSI-to-SCSI controller. Check the
documentation for what controllers can be used. A hardware solution is
usually faster, and perhaps also safer, but comes at a significant cost.
-->
Linux で RAID を実現するには、
カーネルの md モジュールを使ってソフト的に行なう方法、
Linux でサポートされているコントローラ (PCI-to-SCSI) を使って
ハードウェア的に行なう方法、
SCSI-to-SCSI のコントローラを使う方法の三つがあります。
ハード的な方法のほうが高速ですし、
おそらく安全でもあるでしょう。しかしお金もかかります。

<!--O
A summary of available hardware RAID solutions for Linux is available
at
<url url="http://www.Linux-Consulting.com/Raid/Docs/raid_hw.txt"
    name="Linux Consulting">.
-->
Linux で利用できるハードウェア RAID に関するまとめは
<url url="http://www.Linux-Consulting.com/Raid/Docs/raid_hw.txt"
    name="Linux Consulting">
で見ることができます。

<sect2>SCSI-to-SCSI<label id="SCSI-to-SCSI">
<p>
<nidx>disk!technologies!RAID!SCSI-to-SCSI</nidx>
<!--O
SCSI-to-SCSI controllers are usually implemented as complete cabinets
with drives and a controller that connects to the computer with a
second SCSI bus. This makes the entire cabinet of drives look like a
single large, fast SCSI drive and requires no special RAID driver. The
disadvantage is that the SCSI bus connecting the cabinet to the
computer becomes a bottleneck.
-->
SCSI-to-SCSI のコントローラは、
通常一つのキャビネットにドライブと一緒に収められており、
コントローラのもう片方の SCSI バスでコンピュータに繋ぐようになっています。
つまりキャビネット全体が、大きく高速な一つの SCSI ドライブとして見え、
特別な RAID ドライバは必要としないのです。
欠点としては、キャビネットとコントローラを繋ぐ
SCSI バスがボトルネックになることが挙げられます。

<!--O
A significant disadvantage for people with large disk farms is that there
is a limit to how many SCSI entries there can be in the <!-\- <tt>/dev</tt> -\->
<htmlurl url="file:///dev/"
    name="/dev">
directory. In these cases using SCSI-to-SCSI will conserve entries.
-->
巨大なディスクファームを作る人たちにとっての大きな問題は、
<htmlurl url="file:///dev/"
    name="/dev">
ディレクトリに置かれる SCSI ドライブのエントリには制限があるということです。
このような場合 SCSI-to-SCSI を使えばエントリをあまり消費しないですみます。

<!--O
Usually they are configured via the front panel or with a terminal
connected to their on-board serial interface.
-->
通常はフロントパネルから、
あるいはオンボードのシリアルインターフェースに接続した端末から
設定が行えるようになっています。

<!--O
Some manufacturers of such systems are
<url url="http://www.cmd.com"
    name="CMD">
and
<url url="http://www.syred.com"
    name="Syred">
whose web pages describe several systems.
-->
このようなシステムを作っているメーカとしては
<url url="http://www.cmd.com" name="CMD"> や
<url url="http://www.syred.com" name="Syred">
などがあります。 web ページにいくつかのシステムに関する説明があります。


<sect2>PCI-to-SCSI<label id="PCI-to-SCSI">
<p>
<nidx>disk!technologies!RAID!PCI-to-SCSI</nidx>
<!--O
PCI-to-SCSI controllers are, as the name suggests,
connected to the high speed PCI
bus and is therefore not suffering from the same bottleneck as the
SCSI-to-SCSI controllers. These controllers require special drivers
but you also get the means of controlling the RAID configuration over
the network which simplifies management.
-->
PCI-to-SCSI コントローラは、名前からもわかる通り高速な PCI バスを使うので、
SCSI-to-SCSI のようなボトルネックに悩まされずにすみます。
これらのコントローラには特殊なドライバが必要ですが、
RAID の設定をネットワーク越しに行うような手段もあるので、
管理は単純化できます。

<!--O
Currently only a few families of PCI-to-SCSI host adapters
are supported under Linux.
-->
Linux でサポートされている PCI-to-SCSI ホストアダプタの製品ラインアップは、
現在はまだあまりたくさんはありません。

<descrip>

<tag/DPT/
<!--O
The oldest and most mature is a range of controllers from
<url url="http://www.dpt.com"
    name="DPT">
including SmartCache I/III/IV and SmartRAID I/III/IV controller families.
These controllers are supported by the EATA-DMA driver in
the standard kernel. This company also has an informative
<url url="http://www.dpt.com"
    name="home page">
which also describes various general aspects
of RAID and SCSI in addition to the product related information.
-->
もっとも歴史があり、またもっともラインアップの充実したコントローラは
<url url="http://www.dpt.com" name="DPT">
から入手できます。 SmartCache I/III/IV と SmartRAID I/III/IV
コントローラのファミリがあります。
これらのコントローラは、
標準カーネルの EATA-DMA ドライバでサポートされています。
<url url="http://www.dpt.com/" name="DPT のホームページ">
にも有益な情報があります。製品の情報だけでなく、
RAID や SCSI に関する一般的な解説も読むことができます。

<!--O
More information from  the author of the DPT controller drivers
(EATA* drivers) can be found at his pages on
-->
<!-- Old links updated 971021
<url url="http://www.i-connect.net/&tilde;mike/scsi/"
    name="SCSI">
and
<url url="http://www.i-connect.net/&tilde;mike/scsi/dpt/"
    name="DPT">.
 -->
<!--O
<url url="http://www.uni-mainz.de/&tilde;neuffer/scsi/"
    name="SCSI">
and
<url url="http://www.uni-mainz.de/&tilde;neuffer/scsi/dpt/"
    name="DPT">.
-->
DPT コントローラ用ドライバ (EATA* ドライバ) の著者が書いたページには
<url url="http://www.uni-mainz.de/&tilde;neuffer/scsi/"
    name="SCSI">
と
<url url="http://www.uni-mainz.de/&tilde;neuffer/scsi/dpt/"
    name="DPT">
に関するより詳細な情報があります。

<!--O
These are not the fastest but have a good track record of
proven reliability.
-->
DPT のコントローラは最速というわけではありませんが、
長く使われており、その信頼性は証明済みです。

<!--O
Note that the maintenance tools for DPT controllers currently
run under DOS/Win only so you will need a small DOS/Win partition
for some of the software. This also means you have to boot the
system into Windows in order to maintain your RAID system.
-->
DPT コントローラのメンテナンスツールは、現在のところ
DOS/Win でしか動作しません。
したがって小さな DOS/Win のパーティションを作って、
いくつかソフトを入れておく必要があります。
またこの RAID システムを管理するには、
システムを Windows でブートしなければならないわけです。

<tag/ICP-Vortex/
<!--O
A very recent addition is a range of controllers from
<url url="http://www.icp-vortex.com"
    name="ICP-Vortex">
featuring up to 5 independent channels and very fast hardware
based on the i960 chip. The Linux driver was written by the
company itself which shows they support Linux.
-->
ごく最近追加されたコントローラのシリーズで、情報は
<url url="http://www.icp-vortex.com"
    name="ICP-Vortex">
にあります。五つの独立したチャンネルをもち、
i960 チップを用いた非常に高速なハードウェアになっています。
Linux のドライバはメーカ自身によって書かれており、
もちろん Linux をサポートすることも表明されています。

<!--O
As ICP-Vortex supplies the maintenance software for Linux it is
not necessary with a reboot to other operating systems for the
setup and maintenance of your RAID system. This saves you also
extra downtime.
-->
ICP-Vortex は Linux 用のメンテナンスソフトウェアを供給しており、
RAID システムの設定や管理に他の OS で再起動する必要はありません。
したがってダウンタイムが少なくて済みます。

<tag/Mylex DAC-960/
<!--O
This is one of the latest entries which is out in early beta.
More information as well as drivers are available at
<url url="http://www.dandelion.com/Linux/DAC960.html"
    name="Dandelion Digital's Linux DAC960 Page">.
-->
つい最近追加されたもので、現在ベータ版の初期段階です。
詳細な情報やドライバは
<url url="http://www.dandelion.com/Linux/DAC960.html"
    name="Dandelion Digital's Linux DAC960 Page">.
から入手してください。

<tag/Compaq Smart-2 PCI Disk Array Controllers/
<!--O
Another very recent entry and currently in beta release is the
<url url="http://www.insync.net/&tilde;frantzc/cpqarray.html"
    name="Smart-2">
driver.
-->
これもごくごく最近追加されたもので、現在
<url url="http://www.insync.net/~frantze/cpqarray.html"
    name="Smart-2">
用のドライバはベータリリースの段階です。

<tag/IBM ServeRAID/
<!--O
IBM has released their
<url url="http://www.developer.ibm.com/welcome/netfinity/serveraid_beta.html"
    name="driver">
as GPL.
-->
IBM は彼らの
<url url="http://www.developer.ibm.com/welcome/netfinity/serveraid_beta.html"
    name="ドライバ">
を GPL で公開しています。

</descrip>

<!-- 
SCSI-to-SCSI-controllers are small computers themselves, often with
a substantial amount of cache RAM. To the host system they mask
themselves as a gigantic, fast and reliable SCSI disk whereas to
their disks they look like the computer's SCSI host adapter. Some of
these controllers have the option to talk to multiple hosts
simultaneously. Since these controllers look to the host as a
normal, albeit large SCSI drive they need no special support from
the host system. Usually they are configured via the front panel or
with a vt100 terminal emulator connected to their on-board serial
interface.

Very recently I have heard that Syred also makes SCSI-to-SCSI
controllers that are supported under Linux. I have no more information
about this yet but will come back with more information soon. In the
mean time check out their
<url url="http://www.syred.com"
    name="home">
pages for more information.
 -->

<!--O
<sect2>Software RAID<label id="soft-raid">
-->
<sect2>ソフトウェア RAID
<p>
<nidx>disk!technologies!RAID!Software RAID</nidx>

<!--O
A number of operating systems offer software RAID using
ordinary disks and controllers. Cost is low and performance
for raw disk IO can be very high.
As this can be very CPU intensive it increases the load noticeably
so if the machine is CPU bound in performance rather then IO bound
you might be better off with a hardware PCI-to-RAID controller.
-->
普通のディスクとコントローラを使ってソフトウェアで RAID を実現する手法は
多くの OS で可能です。価格コストは低く、
raw ディスク I/O を非常に高速にできます。
これは CPU にかかる負荷が極めて大きいので、
導入しようとしているマシンの制限が I/O ではなく CPU にある場合は、
後述するハードウェア的な PCI-to-RAID コントローラを利用するのが良いでしょう。

<!--O
Real cost, performance and especially reliability of software
vs. hardware RAID is a very controversial topic. Reliability
on Linux systems have been very good so far.
-->
ソフトウェア RAID とハードウェア RAID との
導入コスト、性能、そして特に信頼性に関する比較は、
非常に古くから続いている話題です。
Linux の信頼性に関しては、現在では非常に優れているとされています。

<!--O
The current software RAID project on Linux is the <tt/md/ system
(multiple devices) which offers much more than RAID so it is
described in more details later.
-->
Linux における現在の ソフトウェア RAID プロジェクトは
<tt/md/ (multiple devices) です。
これは RAID 以外の機能もたくさん備えているので、
後ほどより詳しく紹介します。


<!--O
<sect2>RAID Levels<label id="raid-levels">
-->
<sect2>RAID のレベル<label id="raid-levels">
<p>
<nidx>disk!technologies!RAID!RAID levels</nidx>
<!--O
RAID comes in many levels and flavours which I will give a brief
overview of this here. Much has been written about it and the
interested reader is recommended to read more about this in the
<url url="http://ostenfeld.dk/&tilde;jakob/Software-RAID.HOWTO/"
    name="Software RAID HOWTO">.
-->
RAID には何段階かのレベルがあり、それぞれ異なった機能を持っています。
ここではこれらの内容について簡単に説明します。
<url url="http://ostenfeld.dk/&tilde;jakob/Software-RAID.HOWTO/"
    name="Software RAID HOWTO">
にはもっとずっと詳細な情報があります。
RAID に興味を持たれた方は参考にしてください。

<itemize>

<!--O
<item>RAID <em/0/ is not redundant at all but offers the best
throughput of all levels here. Data is striped across a number of
drives so read and write operations take place in parallel across
all drives. On the other hand if a single drive fail then
everything is lost. Did I mention backups?
-->
<item>RAID <em/0/ はデータの冗長性を全く持ちません。
しかし入出力のスループットは最高です。
それぞれのデータは複数のドライブに分割して書き込まれる
(ストライピングといいます) ので、
read/write が並行して同時に行われます。
その代わり、
ひとつのドライブだけでも壊れてしまうとすべてのデータが失われます。
バックアップのことはもう言いましたよね？

<!--O
<item>RAID <em/1/ is the most primitive method of obtaining redundancy
by duplicating data across all drives. Naturally this is
massively wasteful but you get one substantial advantage which is
fast access.
The drive that access the data first wins. Transfers
are not any faster than for a single drive, even though you might
get some faster read transfers by using one track reading per
drive.
-->
<item>RAID <em/1/ はデータの冗長性を
もっとも原始的な手法で実現しています。
すべてのドライブのデータを 2 重化しているのです。
もちろん容量の点では非常に損なのですが、
アクセス速度の点からは多少の利点があります。
データをアクセスする際に、
先にシーク動作を完了したドライブからデータが読み取られるからです。
転送速度はドライブが一台の時より速くはできません。
ドライブそれぞれから 1 トラックずつ読み込めば、
多少は読み出し転送は速くなるかもしれませんが。

<!--O
Also if you have only 2 drives this is the only method of achieving
redundancy.
-->
もしドライブが 2 台しかない場合は、
この方法がデータ冗長性を持たせる唯一の方法となります。

<!--O
<item>RAID <em/2/ and <em/4/ are not so common and are not covered
here.
-->
<item>RAID <em/2/ と <em/4/ はそれほど一般的ではないので、
ここでは省略します。

<!--O
<item>RAID <em/3/ uses a number of disks (at least 2) to store data
in a striped RAID 0 fashion. It also uses an additional redundancy
disk to store the XOR sum of the data from the data disks. Should
the redundancy disk fail, the system can continue to operate as if
nothing happened. Should any single data disk fail the system can
compute the data on this disk from the information on the redundancy
disk and all remaining disks. Any double fault will bring the whole
RAID set off-line.
-->
<item>RAID <em/3/ は 2 台以上のディスクを使い、
データを RAID 0 のストライピングのような形で記録します。
また冗長性を保持するディスク (redundancy disk) が追加されており、
データディスクからのデータの XOR sum を保持するようになっています。
もし redundancy ディスクが故障しても、
システムは何事もなかったように動作できます。
データディスクのどれかひとつが故障しても、
その上にあったデータは残りのデータディスクと
redundancy ディスクのデータとから計算できます。
ただし同時にどれか 2 台の故障が起きた場合は、
RAID 上のすべてのデータは失われます。

<!--O
RAID 3 makes sense only with at least 2 data disks (3 disks
including the redundancy disk). Theoretically there is no limit for
the number of disks in the set, but the probability of a fault
increases with the number of disks in the RAID set. Usually the
upper limit is 5 to 7 disks in a single RAID set.
-->
RAID 3 は、少なくとも 2 台のデータディスク
(redundancy ディスクを入れると 3 台のディスク)
がなければ意味がありません。
理論的には組にできるディスクの台数に制限はありませんが、
台数が増えると故障の確率も増加していきます。
通常一つの RAID セットあたりのディスク台数は
5 から 7 台程度になっていることが多いでしょう。

<!--O
Since RAID 3 stores all redundancy information on a dedicated disk
and since this information has to be updated whenever a write to any
data disk occurs, the overall write speed of a RAID 3 set is limited
by the write speed of the redundancy disk. This, too, is a limit for
the number of disks in a RAID set. The overall read speed of a RAID
3 set with all data disks up and running is that of a RAID 0 set
with that number of data disks. If the set has to reconstruct data
stored on a failed disk from redundant information, the performance
will be severely limited: All disks in the set have to be read and
XOR-ed to compute the missing information.
-->
RAID 3 で冗長性情報の保存されているディスクはある特定のものになっています。
この情報は、どこかのデータディスクに書き込みが行われるたびに
更新しなければなりませんから、 RAID 3 セットの書き込み性能は
redundancy ディスクの速度によって律速されることになります。
一方 RAID 3 の読み込み性能は、
データディスクの台数と同じ台数構成の RAID 0 と等しくなります。
どれかのディスクが故障して、
そのディスクに保存されていたデータを
冗長性情報から再構成しなければならない場合は、性能は非常に低下します。
すべてのディスクで読み込みを行い、
XOR 計算を行って失われた情報を回復しなければならないからです。

<!--O
<item>RAID <em/5/ is just like RAID 3, but the redundancy
information is spread on all disks of the RAID set. This improves
write performance, because load is distributed more evenly between
all available disks.
-->
<item>RAID <em/5/ は RAID 3 と似ていますが、
冗長情報が RAID セットのすべてのディスクに少しずつ保存されています。
これによって書き込み性能が向上しています。
負荷がすべてのディスクに分散するからです。

</itemize>

<!--O
There are also hybrids available based on RAID 0 or 1 and one other
level. Many combinations are possible but I have only seen a few
referred to. These are more complex than the above mentioned
RAID levels.
-->
RAID 0 や 1 を他のレベルと組み合わせて使うこともできます。
様々な組み合わせが可能なはずですが、私が見たことがあるのは 2〜3 種類です。
これらは上に紹介した RAID の各レベルよりもずっと複雑なシステムになります。

<!--O
RAID <em>0/1</em> combines striping with duplication which
gives very high transfers combined with fast seeks as well as
redundancy. The disadvantage is high disk consumption as well as
the above mentioned complexity.
-->
RAID <em>0/1</em> はストライピングと二重化を組み合わせたもので、
非常に速い転送速度とシーク速度、およびデータ冗長性が得られます。
欠点は消費するディスク容量が大きいという点と、
先程触れたようにシステムが複雑になってしまうという点です。

<!--O
RAID <em>1/5</em> combines the speed and redundancy benefits of
RAID5 with the fast seek of RAID1. Redundancy is improved compared
to RAID 0/1 but disk consumption is still substantial. Implementing
such a system would involve typically more than 6 drives, perhaps
even several controllers or SCSI channels.
-->
RAID <em>1/5</em> の組み合わせは冗長度確保における RAID 5 の優位性と
シーク速度における RAID 1 の優位性を組み合わせたものです。
冗長性は RAID 0/1 に比べて改善されますが、
それでもディスク消費はそれなりになります。
このようなシステムは通常 6 台以上のドライブから構成されます。
複数のコントローラや SCSI チャンネルが利用される場合もあるでしょう。


<!--O
<sect1>Volume Management<label id="vol-mgmnt">
-->
<sect1>ボリューム管理<label id="vol-mgmnt">
<p>
<nidx>disk!technologies!volume management</nidx>
<!--O
Volume management is a way of overcoming the constraints of fixed
sized partitions and disks while still having a control of where
various parts of file space resides. With such a system you can
add new disks to your system and add space from this drive to parts
of the file space where needed, as well as migrating data out from
a disk developing faults to other drives before catastrophic failure
occurs.
-->
ボリューム管理 (volume management) は
パーティションやディスクの容量が固定されていることによる制限を
(他に使えるファイル領域がある場合に) なくしてしまうものです。
新しいディスクをシステムに追加すれば、
このドライブの領域をファイルシステムの好きな部分に追加できるのです。
また壊れかけているディスクからデータを別のドライブに移して、
災害を避けたりすることもできます。

<!--O
The system developed by
<url url="http://www.veritas.com"
    name="Veritas">
has become the defacto standard for logical volume management.
-->
<url url="http://www.veritas.com"
    name="Veritas">
によって開発されたシステムが logical ボリューム管理システムの
デファクトスタンダードになっているようです。

<!--O
Volume management is for the time being an area where Linux is lacking.
-->
現在のところでは、 Linux にはボリューム管理の分野は欠けています。

<!--
One is the virtual partition system project
<!-\- <url url="http://www.uiuc.edu/ph/www/roth" 000503 -\->
<url url="http://www-wsg.cso.uiuc.edu/&tilde;roth/"
    name="VPS">
that will reimplement many of the volume management functions found in
IBM's AIX system. Unfortunately this project is currently on hold.
-->
仮想パーティションシステム (Virtual Partition System) プロジェクトである
<url url="http://www-wsg.cso.uiuc.edu/&tilde;roth/"
    name="VPS">
は、
IBM の AIX システムにあるボリューム管理機能の多くを再実装しようというものです。
しかし残念ながらこのプロジェクトは現在停止しています。


<!--O
Another project is the
<!-\- <url url="http://linux.msede.com/lvm/" 001210 -\->
<url url="http://linux.sistina.com/lvm/"
    name="Logical Volume Manager">
project that is similar to a project by HP.
-->
別のプロジェクトとしては
<url url="http://linux.sistina.com/lvm/"
    name="Logical Volume Manager">
というものもあります。
HP のプロジェクトに似たものです。

<!--O
<sect1>Linux <tt/md/ Kernel Patch
-->
<sect1>Linux <tt/md/ カーネルパッチ
<p>
<nidx>disk!technologies!md</nidx>
<nidx>disk!technologies!raid</nidx>
<nidx>disk!technologies!striping</nidx>
<nidx>disk!technologies!translucence</nidx>
<!--O
The Linux Multi Disk (md) provides a number of block level features
in various stages of development.
-->
Linux Multi Disk (md) はブロックレベルの機能を数多く提供します。
開発の水準は方式によって異なります。

<!--O
RAID 0 (striping) and concatenation are very solid and in production quality
and also RAID 4 and 5 are quite mature.
-->
RAID 0 (ストライピング) と concatination (連結) とは非常に安定しており、
製品クォリティと言えます。 RAID 4 と RAID 5 もかなり成熟しています。

<!--O
It is also possible to stack some
levels, for instance mirroring (RAID 1) two pairs of drives,
each pair set up as striped disks (RAID 0),
which offers the speed of RAID 0 combined with the reliability of RAID 1.
-->
いくつかのレベルを組み合せることも可能で、
例えばストライピング (RAID 0) させたドライブ 2 台からなる組を二つ用意して、
それらを互いにミラーさせる (RAID 1) こともできます。
RAID 0 の速度と RAID 1 の信頼性とを組み合せることができるわけです。

<!--O
In addition to RAID this system offers (in alpha stage) block level
volume management and soon also translucent file space.
Since this is done on the block level it can be used in combination
with any file system, even for <tt/fat/ using Wine.
-->
RAID に加えて、 <tt/md/ システムではブロックレベルの
ボリューム管理システムを提供しています (アルファレベルですが)。
これはブロックレベルで行われるので、
任意のファイルシステムと組み合わせることができます。
<tt/FAT/ と Wine でさえも利用が可能です。

<!--O
Think very carefully what drives you combine so you can operate all drives
in parallel, which gives you better performance and less wear. Read more
about this in the documentation that comes with <tt/md/.
-->
どのドライブを組み合せればすべてのドライブを並列動作させることができるか、
充分に考えてください。
報酬は性能の向上と故障率の低下という形で戻ってくるはずです。
より詳しくは <tt/md/ に付属の文書を読んでください。

<!-- radical rework 000123 0.23f
<!-\-O
Unfortunately the documentation is rather old and in parts misleading and
only refers to <tt/md/ version 0.35 which uses old style setup.
The new system is very different and will soon be released as version 1.0
but is currently undocumented. If you wish to try it out you should follow
the <tt/linux-raid/ mailing list.
-\->
...といいたいところですが、残念ながらこの文書は古く、
一部誤っている部分があり、また <tt/md/ の 0.35 版の時代の
古い設定方法についてしか触れていません。
新しいシステムはこの設定方法が非常に異なっており、
そろそろ 1.0 版が出るはずですがドキュメントはまだ不十分です。
こちらを試してみたい場合は、
<tt/linux-raid/ メーリングリストを追う必要があるでしょう。

<!-\-O
Documentation is improving and a
<url url="http://ostenfeld.dk/&tilde;jakob/Software-RAID.HOWTO/"
    name="Software RAID HOWTO">
is in progress.
-\->
ドキュメント整備も進行中で、
<url url="http://ostenfeld.dk/&tilde;jakob/Software-RAID.HOWTO/"
    name="Software RAID HOWTO">
も作業中です。
 -->

<!--O
Unfortunately The Linux software RAID has split into two trees,
the old stable versions 0.35 and 0.42 which are documented in the
official
<url url="http://linas.org/linux/Software-RAID/Software-RAID.html"
    name="Software-RAID HOWTO">
and the newer less stable 0.90 series which is documented in the
unofficial
<url url="http://ostenfeld.dk/&tilde;jakob/Software-RAID.HOWTO/"
    name="Software RAID HOWTO">
which is a work in progress.
-->
残念ながら Linux のソフトウェア RAID は 2 つに分岐してしまっています。
古い安定版の 0.35 と 0.42 は
<url url="http://linas.org/linux/Software-RAID/Software-RAID.html"
    name="Software-RAID HOWTO">
に公式版として文書化されています。
新しく、少々不安定な 0.90 のシリーズは、
<url url="http://ostenfeld.dk/&tilde;jakob/Software-RAID.HOWTO/"
    name="Software RAID HOWTO">
に非公式版の文書があります。こちらの作業は進行中です。

<!--O
A 
<url url="http://www-mddsp.enel.ucalgary.ca/People/adilger.online-ext2/"
    name="patch for online growth of <tt/ext2fs/">
is available in early stages
and related work is taking place at
<url url="http://ext2resize.sourceforge.net/"
    name="the ext2fs resize project">
at Sourceforge.
-->
<url url="http://www-mddsp.enel.ucalgary.ca/People/adilger.online-ext2/"
    name="patch for online growth of ext2fs">
も開発初期の段階ですが入手可能です。また関連作業が Sourceforge の
<url url="http://ext2resize.sourceforge.net/"
    name="the ext2fs resize project">
で行われています。


<!-- &&& check positioning on the above... -->

<!--O
Hint: if you cannot get it to work properly you have forgotten to set
the <tt/persistent-block/ flag. Your best documentation is currently
the source code.
-->
ヒント: うまく動かない場合は、 <tt/persistent-block/ フラグを
セットし忘れていないか確認して下さい。
今のところ最上のドキュメントはソースコードです。


<!--O
<sect1>Compression
-->
<sect1>圧縮
<p>
<nidx>disk!technologies!compression</nidx>
<nidx>disk!compression!DouBle</nidx>
<nidx>disk!compression!Zlibc</nidx>
<nidx>disk!compression!dmsdos</nidx>
<nidx>disk!compression!e2compr</nidx>
<!--O
Disk compression versus file compression
is a hotly debated topic especially regarding
the added danger of file corruption. Nevertheless there are several options
available for the adventurous administrators. These take on many forms,
from kernel modules and patches to extra libraries but note that most
suffer various forms of limitations such as being read-only. As development
takes place at neck breaking speed the specs have undoubtedly changed by the
time you read this. As always: check the latest updates yourself. Here only
a few references are given.
-->
ディスクを圧縮するか、それともファイルを圧縮するのかは、
ファイルを壊してしまう危険性を中心的な争点として、
現在でも活発に議論されている内容です。
新しいものが好きなシステム管理者にはいくつかの選択肢があります。
カーネルモジュール、外部ライブラリへのパッチなど色々な手法が存在しますが、
それらの大部分には書き込み不可といったような各種の制限がまだ残っています。
開発は急ピッチで進められており、
この文書が出るころには間違いなくより高機能なものが出ているでしょう。
常に言えることですが最新版をチェックするようにしてください。
ここにはいくつかのポインタのみを示します。

<!--O
<itemize>
<item>DouBle features file compression with some limitations.
<item>Zlibc adds transparent on-the-fly decompression of files as they load.
<item>there are many modules available for reading compressed files or
partitions that are native to various other operating systems though
currently most of these are read-only.
<item>
<url url="http://bf9nt.uni-duisburg.de/mitarbeiter/gockel/software/dmsdos/"
    name="dmsdos">
(currently in version 0.9.2.0) offer many of the compression
options available for DOS and Windows. It is not yet complete but work is
ongoing and new features added regularly.
<item><tt/e2compr/ is a package that extends <tt>ext2fs</tt> with compression
capabilities. It is still under testing and will therefore mainly be of
interest for kernel hackers but should soon gain stability for wider use.
Check the
<!-\- <url url="http://www.netspace.net.au/&tilde;reiter/e2compr.html" -\->
<url url="http://e2compr.memalpha.cx/e2compr/" <!-\- updated 000622 -\->
    name="e2compr homepage">
for more information. I have reports of speed and good stability
which is why it is mentioned here.
</itemize>
-->
<itemize>
<item>DouBle 形式のファイル圧縮。ただしまだいくつかの制限があります。
<item>Zlibc。ファイルがロードされるとき、
その場で透過的な圧縮／伸展を行うものです。
<item>カーネルモジュール。他の OS で用いられている
圧縮ファイルや圧縮パーティションを読むことができます。
ただしいまのところはほとんどのシステムが読み取り専用です。
<item>
<url url="http://bf9nt.uni-duisburg.de/mitarbeiter/gockel/software/dmsdos/"
    name="dmsdos">
現在のバージョン(0.9.2.0) は DOS や Windows で
用いられている圧縮オプションの多くに対応しています。
まだ完全ではありませんが、作業は進行中で、
どんどん新しい機能が追加されています。
<item><tt/e2compr/ は <tt/ext2fs/ に圧縮機能拡張を行うパッケージです。
まだテスト段階で、したがって主に興味を持っているのは
カーネルハッカー達ですが、近いうちに安定し、
広く用いられるようになるでしょう。
詳しい情報は
<url url="http://e2compr.memalpha.cx/e2compr/"
    name="e2compr homepage">
を見てください。
速度も安定性も良好である、というレポートをもらっています。
</itemize>


<sect1>ACL
<p>
<nidx>disk!technologies!ACL</nidx>
<!--O
Access Control List (ACL) offers finer control over file access
on a user by user basis, rather than the traditional owner, group
and others, as seen in directory listings (<tt/drwxr-xr-x/). This
is currently not available in Linux but is expected in kernel 2.3
as hooks are already in place in <tt/ext2fs/.
-->
アクセスコントロールリスト (Access Control List: ACL) は
ユーザによるファイルアクセスをユーザーベースでより細かく管理するものです。
従来用いられてきた所有者・グループ・その他
 (ディレクトリリストに出る <tt/drwxr-xr-x/)
を置き代えることを目的としています。
まだ Linux では利用できませんが、
<tt/ext2fs/ にはすでに開発の足掛りが用意されているので、
カーネル 2.3 では使えるようになるのではないでしょうか。

<sect1><tt/cachefs/
<p>
<nidx>disk!technologies!cachefs</nidx>
<!--O
This uses part of a hard disk to cache slower media such as CD-ROM.
It is available under SunOS but not yet for Linux.
-->
これはハードディスクの一部分を
CD-ROM などの遅いメディアのキャッシュとして利用しようというものです。
SunOS で使えますが、 Linux ではまだです。

<!--O
<sect1>Translucent or Inheriting File Systems
-->
<sect1>透過 (Translucent) ファイルシステム・継承 (Inheriting) ファイルシステム
<p>
<nidx>disk!technologies!translucent</nidx>
<nidx>disk!technologies!inheriting</nidx>
<!--O
This is a copy-on-write system where writes go to a different system
than the original source while making it look like an ordinary file
space. Thus the file space inherits the original data and the
translucent write back buffer can be private to each user.
-->
これは書き込み時コピーのシステムで、
書き込みデータはもとのソースが置かれていたのとは別のシステムに送られます。
一方で、この書き込みデータは通常のファイル空間にあるように見えるのです。
したがってこのファイル空間はオリジナルのデータを継承することになり、
かつ透過的な書き込みバッファはユーザごとに別々にできます。

<!--O
There is a number of applications:
-->
いろいろな応用が考えられます。
<itemize>
<!--O
<item>updating a live file system on CD-ROM, making it flexible, fast
while also conserving space,
-->
<item>CD-ROM live ファイルシステムが更新可能になり、柔軟・高速になります。
領域も節約できます。

<!--O
<item>original skeleton files for each new user, saving space since the
original data is kept in a single space and shared out,
-->
<item>新しいユーザに対するスケルトンデータを用意しておき、
オリジナルデータを一ヶ所に保持しておくことで容量を節約できます。

<!--O
<item>parallel project development prototyping where every user can
seemingly modify the system globally while not affecting other users.
-->
<item>開発プロジェクトを平行して行うとき、
それぞれのユーザが他のユーザに影響を与えず、
ローカルにシステムを変更できます。
</itemize>

<!--O
SunOS offers this feature and this is under development for Linux.
There was an old project called the Inheriting File Systems (<tt/ifs/)
but this project has stopped.
One current project is part of the <tt/md/ system and offers
block level translucence so it can be applied to any file system.
-->
SunOS はこの機能を持っており、 Linux でも開発中です。
Inheriting File System (<tt/ifs/) という古いプロジェクトもありましたが、
これは停止してしまいました。
現在のプロジェクトは <tt/md/ システムの一部となるもので、
ブロックレベルでの透過性を提供しています。
したがってどんなファイルシステムにも適用できます。

<!--O
Sun has an informative
<url url="http://www.sun.ca/white-papers/tfs.html"
    name="page">
on translucent file system.
-->
transluent ファイルシステムについての
<url url="http://www.sun.ca/white-papers/tfs.html"
    name="ためになるページ">
が Sun によって公開されています。

<!--O
It should be noted that
<url url="http://www.rational.com"
    name="Clearcase (now owned by Rational)">
pioneered and popularized translucent filesystems for software
configuration management by writing their own UNIX filesystem.
-->
なお
<url url="http://www.rational.com"
    name="Clearcase (現在は Rational が保有)">
が、彼らの UNIX ファイルシステムによって、
ソフトウェア設定の管理に translucent ファイルシステムを
開発・普及させたことは知っておいて良いでしょう。


<!-- 

    This is the old section, from which I have moved
    various parts to other sections.

<sect2>General File System Consideration
<p>
<nidx>disk!technologies!filesystem considerations</nidx>
In the Linux world <tt>ext2fs</tt> is well established as a
general purpose system.
Still for some purposes others can be a better choice. News spools lend
themselves to a log file based system whereas high reliability data might
need other formats. This is a hotly debated topic and there are currently
few choices available but work is underway. Log file systems also have the
advantage of very fast file checking. Mail servers in the 100 GB class can
suffer file checks taking several days before becoming operational after
rebooting.

The <tt/Minix/ file system is the oldest one, used in some rescue disk
systems but otherwise very little used these days. At one time the
<tt/Xiafs/ was a strong contender to the standard for Linux but seems
to have fallen behind these days.


Adam Richter from Yggdrasil posted recently that they have been
working on a compressed log file based system but that this project is
currently on hold. Nevertheless a non-working version is available on
their FTP server. Check out
<url url="ftp://ftp.yggdrasil.com/private/adam"
    name="the Yggdrasil ftp server">
where special patched versions of the kernel can be found.
Hopefully this will be rolled into the mainstream kernel in the near future.


An alternative project is the
<url url="http://lucien.blight.com/&tilde;c-cook/prof/lfs/"
    name="Logical Volume Manager">
project.



As of July, 23th 1997 <url url="mailto:reiser (at) RICOCHET.NET" name="Hans
Reiser"> has put up the source to his tree based <url
url="http://idiom.com/&tilde;beverly/reiserfs.html" name="reiserfs"> on
the web. While his filesystem has some very interesting features and
is much faster than <tt/ext2fs/, it is still very experimental and
difficult to integrate with the standard kernel. Expect some
interesting developments in the future - this is different from your
"average log based file system for Linux" project, because Hans
already has working code.


There is room for access control lists (ACL) and other unimplemented
features in the existing <tt>ext2fs</tt>, stay tuned for future
updates.



There is also an encrypted file system available but again as this is under
export control from the US, make sure you get it from a legal place.

Also under development is the
<url url="http://www.virtual.net.au/&tilde;rjc/enh-fs.html"
    name="Enhanced File System">
project.



File systems is an active field of academic and industrial
research and development, the results of which are quite often
freely available. Linux has in many cases been a development tool
in such activities so you can expect a lot of continuous work
in this field, stay tuned for the latest development.

One example of a file system research is
<url url="http://www.cs.columbia.edu/&tilde;ezk/research"
    name="Erez Zadok Research">
page.


<sect2>CD-ROM File Systems
<p>
<nidx>disk!technologies!CD-ROM filesystems</nidx>
There has been a number of file systems available for use on CD-ROM systems
and one of the earliest one was the <em/High Sierra/ format, supposedly named
after the hotel where the final agreement took place. This was the precursor
to the <em/ISO 9660/ format which is supported by Linux.
Later there were the <em/Rock Ridge/ extensions which added file system
features such as long filenames, permissions and more.

The Linux iso9660 file system supports both High Sierra as well as
Rock Ridge extensions.

However, once again Microsoft decided it should create another
standard and their latest effort here is called <em/Joliet/ and offers
some internationalisation features.
This is now available in linux kernel 2.0.34 or newer. You need to
enable NLS in order to use it.


In a recent Usenet News posting hpa (at) transmeta.com (H. Peter Anvin)
writes the following the following interesting piece of trivia:
<tscreen><verb>
Trivia:
Joliet is a city outside Chicago; best known for being the site of
the prison where Jake was locked up in the movie "Blues Brothers."
Rock Ridge (the UNIX extensions to ISO 9660) is named
after the (fictional) town in the movie "Blazing Saddles."
</verb></tscreen>
Very important note: it was actually Jake who was locked up. Oops.


<sect2>Compression
<p>
<nidx>disk!technologies!compression</nidx>
Disk compression versus file compression
is a hotly debated topic especially regarding
the added danger of file corruption. Nevertheless there are several options
available for the adventurous administrators. These take on many forms,
from kernel modules and patches to extra libraries but note that most
suffer various forms of limitations such as being read-only. As development
takes place at neck breaking speed the specs have undoubtedly changed by the
time you read this. As always: check the latest updates yourself. Here only
a few references are given.

<itemize>
<item>DouBle features file compression with some limitations.
<item>Zlibc adds transparent on-the-fly decompression of files as they load.
<item>dmsdos (currently in version 0.9.1.2) offer many of the compression
options available for DOS and Windows. It is not yet complete but work is
ongoing and new features added regularly.
<item><tt/e2compr/ is a package that extends <tt>ext2fs</tt> with compression
capabilities. It is still under testing and will therefore mainly be of
interest for kernel hackers but should soon gain stability for wider use.
Check the 
<url url="http://netspace.net.au/&tilde;reiter/e2compr.html"
    name="e2compr homepage">
for more information. I have reports of speed and good stability
which is why it is mentioned here.
</itemize>


<sect2>Other Filesystems
<p>
<nidx>disk!technologies!filesystems, other</nidx>

Also there is the user file system (<tt/userfs/) that allows FTP based file
system and some compression (<tt/arcfs/) plus fast prototyping and many
other features. The <tt/docfs/ is based on this filesystem.

Recent kernels feature the loop or loopback device which can be
used to put a complete file system within a file. There are some
possibilities for using this for making new file systems with
compression, tarring, encryption etc.

Note that this device is unrelated to the network loopback device.


Very recently a compression package that extends <tt>ext2fs</tt> was
announced. It
is still under testing and will therefore mainly be of interest for kernel
hackers but should soon gain stability for wider use.


There is a number of other ongoing file system projects, but these are
in the experimental stage and fall outside the scope of this HOWTO.

 -->


<!--O
<sect1>Physical Track Positioning<label id="physical-track-positioning">
-->
<sect1>トラックの物理的配置<label id="physical-track-positioning">
<p>
<nidx>disk!technologies!physical track positioning</nidx>
<nidx>disk!technologies!track positioning</nidx>
<!--O
This trick used to be very important when drives were slow and small,
and some file systems used to take the varying characteristics into
account when placing files. Although higher overall speed, on board
drive and controller caches and intelligence
has reduced the effect of this.
-->
ここで示すトリックは、かつてドライブが遅くて容量も小さかった頃、
そしてファイルの大きさを見てからファイルの実際の配置を決めるような
ファイルシステムがもてはやされていた頃、にはとても重要なものでした。
しかし速度が非常に向上し、ドライブやコントローラでのキャッシュが
大きく賢くなった現在ではそれほどの意味はなくなってきています。

<!--O
Nevertheless there is still a little to be gained even today. 
As we know, "<it/world dominance/" is soon within reach
but to achieve this "<it/fast/" we need to employ all the tricks
we can use
<!-\- <htmlurl url="http://www.cs.indiana.edu/finger/linux.cs.helsinki.fi/linus" -\->
<htmlurl url="http://www.mit.edu:8001/finger?linus@linux.cs.helsinki.fi"
        name=" ">.
-->
しかし今日においても多少の性能向上の余地は残されています。
そして世界制覇が近づいた今日でさえも、
これを早期に達成するにはわれわれは持ち得るすべての技を
使わなければならないのです
<htmlurl url="http://www.mit.edu:8001/finger?linus@linux.cs.helsinki.fi"
	name="！">

<!--O
To understand the strategy we need to recall this near ancient piece
of knowledge and the properties of the various track locations.
This is based on the fact that transfer speeds generally increase for tracks
further away from the spindle, as well as the fact that it is faster
to seek to or from the central tracks than to or from the inner or outer
tracks.
-->
この手法の意味を理解するためには、現在では失われてしまった知識
「セクタの位置によってディスクの性質がどのように変わるのか」
を理解する必要があります。
ディスクの回転中心から離れたトラックではデータの転送速度は速くなります。
また中間のトラックを起点／終点とするシークは、内側から外側、
外側から内側へのシークよりも速いでしょう。

<!--O
Most drives use disks running at constant angular velocity but use
(fairly) constant data density across all tracks. This means that
you will get much higher transfer rates on the outer tracks than
on the inner tracks; a characteristics which fits the requirements
for large libraries well.
-->
ほとんどのドライブは一定の角速度で回っており、
また各トラックにおけるデータの線密度はだいたい一定になっています。
これはすなわち、外側のトラックでは内側のトラックに比べて
ずっと速い転送が行われるということです。
したがって大きなライブラリなどを置くのに適しています。

<!--O
Newer disks use a logical geometry mapping which differs from the actual
physical mapping which is transparently mapped by the drive itself.
This makes the estimation of the "middle" tracks a little harder.
-->
最近のディスクでは論理ジオメトリマップを使っているものもあります。
これは実際の物理的なマップ (ドライブそのもののマップ) とは異なっているため、
「真ん中辺の」トラックの見当をつけるのが少々難しくなるかもしれません。

<!--O
In most cases track 0 is at the outermost track and this is the general
assumption most people use. Still, it should be kept in mind that there
are no guarantees this is so.
-->
ほとんどの場合トラック 0 は最も外側のトラックであり、
多くの人々がこの仮定を用いています。
しかし、この事には何の保証もないことも心に留めておく必要があります。

<p>
<descrip>
<!--O
<tag/Inner/ tracks are usually slow in transfer, and lying at one
end of the seeking position it is also slow to seek to.
-->
<tag/内側/ セクタの転送速度は遅くなります。
またシークの起点／終点になる場合、シーク動作は遅くなります。

<!--O
This is more suitable to the low end directories such as DOS, root
and print spools.
-->
この部分は高い性能を必要としない領域に割り当てると良いでしょう。
たとえば DOS やルートファイルシステム、プリントスプールなどです。

<!--O
<tag/Middle/ tracks are on average faster with respect to transfers
than inner tracks and being in the middle also on average faster to
seek to.
-->
<tag/中間/
セクタの転送速度は一般に内側より速く、またシーク動作も速いです。

<!--O
This characteristics is ideal for the most demanding parts such as
<tt>swap</tt>, <tt>/tmp</tt> and <tt>/var/tmp</tt>.
-->
この特性はスワップや <tt>/tmp</tt>、<tt>/var/tmp</tt> など、
頻繁に転送要求が来るような領域に適しています。

<!--O
<tag/Outer/ tracks have on average even faster transfer characteristics
but like the inner tracks are at the end of the seek so statistically it
is equally slow to seek to as the inner tracks.
-->
<tag/外側/セクタの転送速度は最も速いですが、
シークタイムは内側と同じように遅くなっています。

<!--O
Large files such as libraries would benefit from a place here.
-->
ライブラリなどの大きなファイルが置かれる領域を
ここに割り当てると良いでしょう。

</descrip>

<!--O
Hence seek time reduction can be achieved by positioning frequently
accessed tracks in the middle so that the average seek distance and
therefore the seek time is short. This can be done either by using
<tt>fdisk</tt> or <tt>cfdisk</tt> to make a partition
on the middle tracks or by first
making a file (using <tt/dd/) equal to half the size of the entire disk
before creating the files that are frequently accessed, after which
the dummy file can be deleted. Both cases assume starting from an
empty disk.
-->
頻繁にアクセスされるセクタをディスクの中ほどに置けば、
シークの際のヘッドの平均移動距離を下げ、
シークタイムを減らすことができます。
このようにするには <tt>fdisk</tt> や
<tt>cfdisk</tt> を実行してパーティションを真ん中あたりに作ったり、
あるいは <tt>dd</tt> コマンドを使って
ディスク容量の半分ほどの大きさのファイルを作り、
その後に頻繁に使われるファイルを作成する、といった方法があります。
後者の方法では作業後にダミーファイルを消しておきます。
いずれも空のディスクを使い始めるときの方法です。

<!--O
The latter trick is suitable for news spools where the empty directory
structure can be placed in the middle before putting in the data files.
This also helps reducing fragmentation a little.
-->
後者の方法はニューススプールに使うと良いでしょう。
データファイルが置かれる前に、
ディレクトリ構造を中ほどのトラックに置くのです。この作業によって、
多少ですがフラグメンテーションが減る効果も期待できます。

<!--O
This little trick can be used both on ordinary drives as well as RAID
systems. In the latter case the calculation for centring the tracks
will be different, if possible. Consult the latest RAID manual.
-->
このちょっとしたおまじないは、普通のファイルシステムでも
RAID システムでも使えます。
RAID では、真ん中当たりのセクタを計算するのが
(不可能とまでは言いませんが) ちょっと難しいかもしれません。
最新の RAID のマニュアルを見てみてください。

<!--O
The speed difference this makes depends on the drives, but a 50 percent
improvement is a typical value.
-->
この作業によって向上する速度はドライブによって異なりますが、
でも多くの場合 50 パーセント程度の向上が見込めます。

<!--O
<sect2>Disk Speed Values<label id="disk-speed-values">
-->
<sect2>ディスクの速度値<label id="disk-speed-values">
<p>
<nidx>disk!technologies!disk speed values</nidx>
<!--O
The same mechanical head disk assembly (HDA) is often available
with a number of interfaces (IDE, SCSI etc) and the mechanical
parameters are therefore often comparable. The mechanics is
today often the limiting factor but development is improving
things steadily. There are two main parameters, usually quoted
in milliseconds (ms):
-->
ディスクヘッドの機械的機構 (head disk assembly: HDA) の同じものが、
異なるインターフェース (IDE や SCSI など) で共用されることは良くあります。
したがって機械的な値はだいたい同じになります。
今日ではこの機械的な部分が速度的な限界を決めていますが、
たゆまぬ開発努力によって着々と物事は進歩しています。
さて、ここには二つの主要なパラメータがあります。
それぞれミリ秒 (ms) 単位で記述されます。

<itemize>
<!--O
<item>Head movement - the speed at which the read-write head
is able to move from one track to the next, called access time.
If you do the mathematics and doubly integrate the seek
first across all possible starting tracks and
then across all possible target tracks you will find that
this is equivalent of a stroke across a third of all tracks.
-->
<item>ヘッド動作 - 読み書きを行うヘッドが、あるトラックから
別のトラックに移動する速度です。アクセス時間とも呼ばれます。
数学が得意な人は、出発点として可能なすべてのトラックと、
到達点として可能なすべてのトラックを考え、
これらを二重積分してみてください。
これは端のトラックからもう一端までを移動するストロークの
1/3 に等しいことがわかるでしょう。

<!--O
<item>Rotational speed - which determines the time taken to
get to the right sector, called latency.
-->
<item>回転速度 - 必要なセクタに到達するまでの時間を決定します。
この時間は待ち時間 (latency) とも呼ばれます。
</itemize>

<!--O
After voice coils replaced stepper motors for the head movement
the improvements seem to have levelled off and more energy is
now spent (literally) at improving rotational speed. This has
the secondary benefit of also improving transfer rates.
-->
ヘッド移動の機構がステッパーモータからボイスコイルに変更されて以降は、
性能の向上は頭打ちになりました。開発のエネルギーは、
現在では事実上回転速度の向上に注力されています。
これによる二次的な効果として、転送速度の向上も期待できます。

<!--O
Some typical values:
-->
以下に典型的な値を挙げておきます。
<tscreen><verb>

                         Drive type


Access time (ms)        | Fast  Typical   Old
---------------------------------------------
Track-to-track             <1       2       8
Average seek               10      15      30
End-to-end                 10      30      70

</verb></tscreen>

<!--O
This shows that the very high end drives offer only marginally
better access times then the average drives but that the old
drives based on stepper motors are significantly worse.
-->
非常にハイエンドなドライブでも、
アクセス時間においては平均的なドライブとたいした差がないことがわかります。
ただしステッパーモーターを用いた古いドライブでは、非常に値は悪いです。

<tscreen><verb>

Rotational speed (RPM)  |  3600 | 4500 | 4800 | 5400 | 7200 | 10000           
-------------------------------------------------------------------
Latency          (ms)   |    17 |   13 | 12.5 | 11.1 |  8.3 |   6.0

</verb></tscreen>

<!--O
As latency is the average time taken to reach a given sector, the
formula is quite simply
-->
待ち時間 (latency) は指定されたセクタに到達するのに必要な時間ですから、
式は非常に簡単で、
<tscreen><verb>
latency (ms) = 60000 / speed (RPM)
</verb></tscreen>
のようになります。

<!--O
Clearly this too is an example of diminishing returns for the
efforts put into development. However, what really takes off
here is the power consumption, heat and noise.
-->
明らかにこの結果からも、開発努力に対する効果が小さいことがわかります。
しかしここでまるっきり無視した点として、電力消費や熱、
ノイズなどの問題があることも忘れてはなりません。


<!--O
<sect1>Yoke
-->
<sect1>Yoke
<p>
<nidx>disk!technologies!yoke</nidx>
<!--O
There is also a
<url url="http://www.it.uc3m.es/&tilde;ptb/cgi-bin/cvs-yoke.cgi"
    name="Linux Yoke Driver">
available in beta which
is intended to do hot-swappable transparent binding of
one Linux block device to another. This means that if you
bind two block devices together,
say <tt>/dev/hda</tt> and <tt>/dev/loop0</tt>,
writing to one device will mean also writing to the other
and reading from either will yield the same result.
-->
<url url="http://www.it.uc3m.es/&tilde;ptb/cgi-bin/cvs-yoke.cgi"
    name="Linux Yoke Driver">
のベータ版もあります。これは Linux のブロックデバイスを
他のブロックデバイスにホットスワップ可能なかたちで
透過的にバインドするものです。
二つのブロックデバイス (例えば
<tt>/dev/hda</tt> と <tt>/dev/loop0</tt>)
をバインドすると、片方のデバイスへ行われた書き込みは
もう片方にも行われることになり、
両者からの読み出しが同じ結果を与えることになります。


<!--O
<sect1>Stacking
-->
<sect1>組み合わせ
<p>
<nidx>disk!technologies!stacking</nidx>
<!--O
One of the advantages of a layered design of an operating system
is that you have the flexibility to put the pieces together
in a number of ways.
For instance you can cache a CD-ROM with <tt/cachefs/ that is
a volume striped over 2 drives. This in turn can be set up
translucently with a volume that is NFS mounted from another machine.
RAID can be stacked in several layers to offer very fast seek and
transfer in such a way that it will work if even 3 drives fail.
The choices are many, limited only by imagination and, probably
more importantly, money.
-->
OS をレイヤー構造に設計して得られる利点の一つは、
要素の組み合せ方法をいろいろ選べることです。
例えば CD-ROM を <tt/cashefs/ でキャッシュし、
そのキャッシュはストライピングした 2 つのドライブから構成したりできます。
あるいは、他のマシンから NFS マウントしたボリュームを用いて、
キャッシュを translucent に設定することもできます。
RAID も何層にも組み合わせることができます。
非常にシークを高速にし、かつ 3 台のディスクが故障しても
継続動作できるようなシステムを作ることも可能です。
組み合わせは無限ですが、想像力の限界か、
あるいは (より重要な要素である) 金銭的な限界によって制限されるでしょう。

<!--O
<sect1>Recommendations
-->
<sect1>お勧め
<p>
<nidx>disk!technologies!recommendations</nidx>
<!--O
There is a near infinite number of combinations available but my
recommendation is to start off with a simple setup without any
fancy add-ons. Get a feel for what is needed, where the maximum
performance is required, if it is access time or transfer speed
that is the bottle neck, and so on. Then phase in each component
in turn. As you can stack quite freely you should be able to
retrofit most components in as time goes by with relatively few
difficulties.
-->
選択可能な組み合せは無限ですが、
しかしまずは特殊な機能は使わないで、簡単な設定からはじめましょう。
そして何が必要なのか、
最大の性能が必要とされるのはどの部分かを感じとってください。
ボトルネックになっているのはアクセス時間なのか転送速度なのか、
などをです。次に各コンポーネントを段階的に試してみましょう。
組み合わせの自由度は極めて大きいです。
経験を積んで様々なコンポーネントを
簡単に組み合わせることができるようになりましょう。

<!--O
RAID is usually a good idea but make sure you have a thorough
grasp of the technology and a solid back up system.
-->
RAID を用いるのは通常は良い考えですが、
このテクニックを完全に理解しておくこと、
しっかりしたバックアップをとっておくことを忘れないように。


<!--O
<sect>Other Operating Systems
-->
<sect>他のオペレーティングシステム
<p>
<nidx>disk!operating systems, other</nidx>
<!--O
Many Linux users have several operating systems installed, often
necessitated by hardware setup systems that run under other operating
systems, typically DOS or some flavour of Windows. A small section on
how best to deal with this is therefore included here.
-->
Linux ユーザの多くは自分の PC に複数の OS をインストールしています。
これは主に、ハードウェア設定用のプログラムが他の OS
(DOS や 各種 Windows) でしか動かないためであることが多いようです。
そこで、このような OS をどのように扱えばよいかについて一章を設けました。

<sect1>DOS
<p>
<nidx>disk!operating systems, other!DOS</nidx>
<!--O
Leaving aside the debate on weather or not DOS qualifies as an operating
system one can in general say that it has little sophistication with
respect to disk operations. The more important result of this is that there
can be severe difficulties in running various versions of DOS on large
drives, and you are therefore strongly recommended in reading the
<em>Large Drives mini-HOWTO</em>. One effect is that you are often better
off placing DOS on low track numbers.
-->
DOS がオペレーティングシステムの名に値するかどうかの議論は
ひとまず置いておきますが、
いずれにしても DOS がディスク操作に関して
非常に原始的なものであることは確かです。
特に問題になるのは、
DOS のいくつかのバージョンでは大きいディスクを扱う際に
重大な障害が生じる可能性があることです。
<em/Large Drives mini-HOWTO/ を読んでおくと良いでしょう。
各種の問題を避けるには
DOS は低位のトラックの領域に置いておくと良いでしょう。

<!--O
Having been designed for small drives it has a rather unsophisticated
file system (<tt/fat/) which when used on large drives will allocate
enormous block sizes. It is also prone to block fragmentation which
will after a while cause excessive seeks and slow effective transfers.
-->
DOS は小さなドライブ向けに設計されてきたものですので、
ファイルシステム (<em/fat/) も洗練されたものではありません。
FAT で大きなドライブを扱おうとすると、
あてがわれるブロックのサイズは巨大なものになってしまいます。
また FAT ではブロックのフラグメンテーションが起こりやすく、
しばらく使うとシークが頻繁に生じるようになり、
実効的な転送速度が低下してしまいます。

<!--O
One solution to this is to use a defragmentation program regularly but
it is strongly recommended to back up data and verify the disk before
defragmenting. All versions of DOS have <tt/chkdsk/ that can do some
disk checking, newer versions also have <tt/scandisk/ which is somewhat
better. There are many defragmentation programs available, some versions
have one called <tt/defrag/. Norton Utilities have a large suite of
disk tools and there are many others available too.
-->
フラグメンテーションに対する一つの解は、
デフラグメントプログラムを定期的に動作させることですが、
これを行う前にはデータをバックアップし、
ディスクをベリファイしておくことを強くお勧めします。
DOS のすべてのバージョンには
<tt/chkdsk/ というディスクを検査するプログラムが付属しています。
また最近のバージョンには
<tt/scandisk/ というもう少し良いプログラムもあります。
デフラグメントを行うプログラムもたくさんあります。
バージョンによっては DOS にも <tt/defrag/ というツールがあります。
Norton Utilities は多くのディスクツールを集めたもので、
ディスク向け以外にも色々なツールが付属してきます。

<!--O
As always there are snags, and this particular snake in our drive
paradise is called <em/hidden files/. Some vendors started to use
these for copy protection schemes and would not take kindly to being
moved to a different place on the drive, even if it remained in the
same place in the directory structure. The result of this was that
newer defragmentation programs will not touch any hidden file, which
in turn reduces the effect of defragmentation.
-->
デフラグの際には hidden 属性を持ったファイルが邪魔になることがあります。
ベンダによってはこのファイルをコピー防止のキーに使っており、
これを他のディレクトリに移動すると
ソフトが動かないようにしている場合があります。
従って最近のデフラグツールでは
hidden 属性を持ったファイルは移動しないようにしており、
結果としてデフラグメントの効率が低下してしまっています。

<!--O
Being a single tasking, single threading and single most other things
operating system there is very little gains in using multiple drives
unless you use a drive controller with built in RAID support of some
kind.
-->
DOS はシングルタスク、シングルスレッド、
その他いろいろな面に関して「シングル」ですから、
複数のドライブを使ってもほとんどメリットはありません。
ただし RAID をビルトインでサポートした
ドライブコントローラを利用する場合は例外ですが。

<!--O
There are a few utilities called <tt/join/ and <tt/subst/ which
can do some multiple drive configuration but there is very little
gains for a lot of work. Some of these commands have been removed in
newer versions.
-->
<tt/join/ や <tt/subst/ といった、
複数ドライブ用の設定ユーティリティもいくつか存在しますが、
ほとんどの場合は役に立ちません。
最近のバージョンでは削除されたものもあるようです。

<!--O
In the end there is very little you can do, but not all hope is lost.
Many programs need fast, temporary storage, and the better behaved
ones will look for environment variables called <tt/TMPDIR/ or
<tt/TEMPDIR/ which you can set to point to another drive. This is
often best done in <tt/autoexec.bat/.
-->
DOS に関して手を入れられるところはほとんどありませんが、
少ないながら例外もあります。
多くのプログラムでは高速な一時領域を必要としますが、
良くできたプログラムでは <tt/TMPDIR/ や
<tt/TEMPDIR/ といったような環境変数を参照します。
これら分離したドライブに設定しておくと良いでしょう。
<tt/autoexec.bat/ などで以下のように設定します。

<code>
SET TMPDIR=E:/TMP
SET TEMPDIR=E:/TEMP
</code>

<!--O
Not only will this possibly gain you some speed but also it can
reduce fragmentation.
-->
速度の向上だけでなく、フラグメンテーションが減る効果も期待できます。

<!--O
There have been reports about difficulties in removing multiple primary
partitions using the <tt/fdisk/ program that comes with DOS. Should this
happen you can instead use a Linux rescue disk with Linux <tt/fdisk/ to
repair the system.
-->
DOS の <tt/fdisk/ プログラムでは、
複数の primary パーティションを削除するのが難しい、
という報告もあるようです。
この場合は Linux のレスキューディスクから起動し、
Linux の <tt/fdisk/ でシステムを修理してください。

<!--O
Don't forget there are other alternatives to DOS, the most well known
being
<url url="http://www.caldera.com/dos/"
    name="DR-DOS">
from
<url url="http://www.caldera.com/"
    name="Caldera">.
This is a direct descendant from DR-DOS from Digital Research.
It offers many features not found in the more common DOS, such
as multi tasking and long filenames.
-->
DOS には代替品があることも知っておくと良いでしょう。
もっとも有名なのは
<url url="http://www.caldera.com/" name="Caldera">
の
<url url="http://www.caldera.com/dos/" name="DR-DOS">
です。これは Digital Research の DR-DOS の直系の子孫です。
より使われている DOS にはない、
多くの機能 (マルチタスクや長いファイル名など) を備えています。

<!--O
Another alternative which also is free is
<url url="http://www.freedos.org/"
    name="Free DOS">
which is a project under development. A number of free utilities
are also available.
-->
他にもフリーなものとして
<url url="http://www.freedos.org/" name="Free DOS">
があります。これは開発中のプロジェクトです。
一緒に使えるフリーなユーティリティもたくさんあります。

<sect1>Windows
<p>
<nidx>disk!operating systems, other!Windows</nidx>
<!--O
Most of the above points are valid for Windows too, with the exception
of Windows95 which apparently has better disk handling, which will get
better performance out of SCSI drives.
-->
前節で挙げた点は Windows にも当てはまります。
ただし Windows95 ではより良いディスク管理が行われており、
SCSI のドライブでもその性能を引き出すことができています。

<!--O
A useful thing is the introduction of long filenames, to read these from
Linux you will need the <tt/vfat/ file system for mounting these partitions.
-->
ロングファイルネームがサポートされたことは大きいですね。
これを Linux から読むには
<tt/vfat/ ファイルシステムを用いてパーティションをマウントします。

<!--O
Disk fragmentation is still a problem. Some of this can be avoided by
doing a defragmentation immediately before and immediately after installing
large programs or systems. I use this scheme at work and have found it
to work quite well. Purging unused files and emptying the waste basket first
can improve defragmentation further.
-->
ディスクのフラグメンテーションは依然解決していません。
この問題は、大きなプログラムをシステムにインストールする直前・直後に
デフラグメントツールを使えばある程度は回避できます。
私はこの方法を採用していますが、満足の行く結果が得られています。
使っていないファイルを削除して解放領域を大きくとると、
デフラグメントの効果はさらに高くなります。

<!--O
Windows also use swap drives, redirecting this to another drive can give
you some performance gains. There are several mini-HOWTOs telling you how
best to share swap space between various operating systems.
-->
Windows はスワップドライブを使います。これを別のドライブにすると、
ある程度の性能向上が期待できるでしょう。
スワップ領域を複数のオペレーティングシステムの間で共有する方法に関する
mini-HOWTO もあるようです。


<!-- added 030298, need more info here, low priority for now -->

<!--O
The trick of setting <tt/TEMPDIR/ can still be used but not all
programs will honour this setting. Some do, though. To get a good
overview of the settings in the control files you can run <tt/sysedit/
which will open a number of files for editing, one of which is the
<tt/autoexec/ file where you can add the <tt/TEMPDIR/ settings.
-->
<tt/TEMPDIR/ を指定する、というテクニックは Windows でも有効ですが、
すべてのプログラムがこの設定を見てくれるわけではありません
(もちろん見てくれるプログラムもあります)。
各種コントロールファイルでの設定情報を閲覧するには
<tt/sysedit/ が便利です。
これはたくさんのファイルをオープンし、編集もできます。
ファイルの中のひとつ、
<tt/autoexec/ ファイルに <tt/TEMPDIR/ の設定を追加できます。

<!--O
Much of the temporary files are located in the <tt>/windows/temp</tt>
directory and changing this is more tricky. To achieve this you can
use <tt/regedit/ which is rather powerful and quite capable of
rendering your system in a state you will not enjoy, or more
precisely, in a state much less enjoyable than windows in general.
Registry database error is a message that means seriously bad news.
Also you will see that many programs have their own private temporary
directories scattered around the system.
-->
一時ファイルのほとんどは <tt>/windows/temp</tt> ディレクトリに
保存されます。これを変更するには、もう少々テクニックが必要です。
これには <tt/regedit/ を使います。これは強力なコマンドで、
システムを不愉快な状態にしてしまうこともできます。
もっと正確に言うと、そのままの Windows よりも
もっとずっと不愉快な状態にしてしまう能力があります。
「レジストリデータベースのエラー」が、
この悪いニュースを伝えるメッセージです。
また多くのプログラムでは、それぞれ独自の一時ディレクトリを定義しており、
これがシステム中に散らばっていることも覚えておいてください。

<!--O
Setting the swap file to a separate partition is a better idea and much
less risky. Keep in mind that this partition cannot be used for anything
else, even if there should appear to be space left there.
-->
スワップファイルを分離されたパーティションに置くのは良いアイディアで、
ずっとリスクも低いです。
ただしこのパーティションは他のどんな用途にも用いないようにしてください。
たとえ空いているように見えても、です。

<!--O
It is now possible to read <tt/ext2fs/ partitions from Windows,
either by mounting the partition using
<url url="http://www.yipton.demon.co.uk/"
    name="FSDEXT2">
or by using a file explorer like tool called
<!-\- <url url="http://uranus.it.swin.edu.au/&tilde;jn/linux/Explore2fs.html" 000502 -\->
<url url="http://uranus.it.swin.edu.au/&tilde;jn/linux/explore2fs.htm"
    name="Explore2fs">.
-->
現在では <tt/ext2fs/ パーティションを
Windows から読むことも可能になりました。
<url url="http://www.yipton.demon.co.uk/" name="FSDEXT2">
でパーティションをマウントするか、
<url url="http://uranus.it.swin.edu.au/&tilde;jn/linux/explore2fs.htm"
    name="Explore2fs">
と呼ばれるエクスプローラ風のツールを使います。


<sect1>OS/2
<p>
<nidx>disk!operating systems, other!OS/2</nidx>
<!--O
The only special note here is that you can get file system driver for
OS/2 that can read an <tt/ext2fs/ partition.
Matthieu Willm's ext2fs Installable File System for OS/2 can be found at
<url url="ftp://ftp-os2.nmsu.edu/pub/os2/system/drivers/filesys/ext2_240.zip"
    name="ftp-os2.nmsu.edu">,
<url url="ftp://sunsite.unc.edu/pub/Linux/system/Filesystems/ext2/ext2_240.zipftp://sunsite.unc.edu/pub/Linux/system/Filesystems/ext2/ext2_240.zip"
    name="Sunsite">,
<url url="ftp://ftp.leo.org/pub/comp/os/os2/drivers/ifs/ext2_240.zip"
    name="ftp.leo.org"> and
<url url="ftp://ftp-os2.cdrom.com/pub/os2/diskutil/ext2_240.zip"
    name="ftp-os2.cdrom.com">.
-->
OS/2 には
<tt/ext2fs/ のパーティションを読むことのできるドライバがあるそうです。
Matthieu Willm による、OS/2 用の ext2fs Installable ファイルシステムは
<url url="ftp://ftp-os2.nmsu.edu/pub/os2/system/drivers/filesys/ext2_240.zip"
    name="ftp-os2.nmsu.edu">,
<url url="ftp://sunsite.unc.edu/pub/Linux/system/filesystems/ext2/ext2_240.zip"
    name="Sunsite">,
<url url="ftp://ftp.leo.org/pub/comp/os/os2/drivers/ifs/ext2_240.zip"
    name="ftp.leo.org"> and
<url url="ftp://ftp-os2.cdrom.com/pub/os2/diskutil/ext2_240.zip"
    name="ftp-os2.cdrom.com">.
などにあります。

<!--O
The IFS has read and write capabilities.
-->
IFS には読み書き両方の機能があります。

<sect1>NT
<p>
<nidx>disk!operating systems, other!Windows/NT</nidx>
<nidx>disk!operating systems, other!NT</nidx>
<nidx>disk!Microsoft!bug</nidx>
<!--O
This is a more serious system featuring most buzzwords known to marketing.
It is well worth noting that it features software striping and other more
sophisticated setups. Check out the drive manager in the control panel.
I do not have easy access to NT, more details on this can take a bit of time.
-->
NT はもう少し本格的なシステムです。
名前もマーケティング向け (New Techonology!) ですね。
NT ではソフト的なストライピングといったような、
より洗練された設定ができます。
コントロールパネルのドライブマネージャをチェックしてください。
私自身は NT を気軽に扱うことができる立場にいないので、
詳細に関する記述は先のことになります。

<!--O
One important snag was recently reported by acahalan at cs.uml.edu :
(reformatted from a Usenet News posting)
-->
最近一つ重要な欠点が <tt/acahalan@cs.uml.edu/ から報告されています。
(以下は Usenet ニュースへのポストを整形しています)

<!--O
NT DiskManager has a serious bug that can corrupt your disk when you have
several (more than one?) extended partitions.  Microsoft provides an
emergency fix program at their web site. See the
<url url="http://www.microsoft.com/kb/"
name="knowledge base">
for more.  (This affects Linux users, because Linux users have extra partitions)
-->
<quote>
NT ディスクマネージャには重大なバグがあり、
複数の (一つ以上の？) 拡張パーティションを扱うと
ディスクを破壊してしまいます。
Microsoft はこの問題を解決したプログラムを
彼らの web サイトで配布しています。
詳細に関しては
<url url="http://www.microsoft.com/kb/" name="knowledge base">
のページから検索してください。
この問題は拡張パーティションを使っている Linux ユーザにも影響します)
</quote>

<!--O
You can now read <tt/ext2fs/ partitions from NT using
<!-\- <url url="http://uranus.it.swin.edu.au/&tilde;jn/linux/Explore2fs.html" 000502 -\->
<url url="http://uranus.it.swin.edu.au/&tilde;jn/linux/explore2fs.htm"
    name="Explore2fs">.
-->
最近では
<url url="http://uranus.it.swin.edu.au/&tilde;jn/linux/explore2fs.htm"
    name="Explore2fs">.
を用いれば、
NT から <tt/ext2fs/ パーティションを読めるようになりました。


<sect1>Sun OS
<p>
<nidx>disk!operating systems, other!SunOS</nidx>
<!--O
There is a little bit of confusion in this area between Sun OS vs. Solaris.
Strictly speaking Solaris is just Sun OS 5.x packaged with Openwindows and
a few other things. If you run Solaris, just type <tt/uname -a/ to see your
version. Parts of the reason for this confusion is that Sun Microsystems
used to use an OS from the BSD family, albeight with a few bits and pieces
from elsewhere as well as things made by themselves. This was the situation
up to Sun OS 4.x.y when they did a "strategic roadmap decision" and decided
to switch over to the official Unix, System V, Release 4 (aka SVR5),
and Sun OS 5 was created.
This made a lot of people unhappy. Also this was bundled with other things
and marketed under the name Solaris, which currently stands at release
7 which just recently replaced version 2.6 as the latest and greatest.
In spite of the large jump in version number this is actually a minor
technical upgrade but a giant leap for marketing.
-->
Sun OS と Solaris の関係については少々混乱があるようです。
単刀直入に言うと、 Solaris は Sun OS 5.x に過ぎません
(Openwindows 等の付属パッケージはありますが)。
Solaris を使っているなら <tt/uname -a/ とすれば現在のバージョンがわかります。
混乱の理由の一部は以下の点にあります。
Sun Microsystems は以前は BSD 系の OS を使っており、
それによそから集めたり自分達で作ったりしたものを併せて配布していました。
Sun OS 4.x.y まではこのような形でしたが、
その後彼らは「将来戦略の選択」をした際に、オフィシャルな Unix である
System V Release 4 (SVR4) へ切り替えることを決定したのでした。
こうして Sun OS 5 が作成されました。
この決定には多くの人々が不満を感じました。
Sun OS 5 にもいくつかのソフトが追加され、
Solaris という名前で販売されるようになりました。
現在は release 7 で、ごく最近 2.6 から更新されて最新版になりました。
バージョン番号には大きなジャンプがありますが、
実際にはマイナーな部分のアップグレードに過ぎません。
でもマーケティング的には大きく飛躍したようです。


<sect2>Sun OS 4
<p>
<nidx>disk!operating systems, other!SunOS 4</nidx>
<!--O
This is quite familiar to most Linux users.
The last release is 4.1.4 plus various patches.
Note however that the file system
structure is quite different and does not conform to FSSTND so any planning
must be based on the traditional structure. You can get some information by
the man page on this: <tt/man hier/. This is, like most man pages, rather brief
but should give you a good start. If you are still confused by the structure
it will at least be at a higher level.
-->
おそらく多くの Linux ユーザに取って馴染み深い OS でしょう。
最後のリリースは 4.1.4 ですが、各種のパッチが出ています。
しかしファイル構造は FSSTND とは大きく異なっていますので、
ディスク配置を行なう際には伝統的な構造に従う必要があります。
<tt/man hier/ することによってこのディレクトリ情報が得られます。
man ページの通例に従って記述はぶっきらぼうなものですが、
出発点としてはよいでしょう。
もしそれでもディレクトリ構造に関して迷うことがあったら、
そのディレクトリはルートに近いところに置いてしまうのが良いでしょう。

<!--O
<sect2>Sun OS 5 (aka Solaris)
-->
<sect2>Sun OS 5  (Solaris)
<p>
<nidx>disk!operating systems, other!SunOS 5</nidx>
<nidx>disk!operating systems, other!Solaris</nidx>
<!--O
This comes with a snazzy installation system that runs under Openwindows, it
will help you in partitioning and formatting the drives before installing the
system from CD-ROM. It will also fail if your drive setup is too far out, and
as it takes a complete installation run from a full CD-ROM in a 1x only drive
this failure will dawn on you after too long time. That is the experience we
had where I used to work. Instead we installed everything onto one drive and then
moved directories across.
-->
Solaris には
Openwindows の下で動くできの良いインストールプログラムが付属しています。
これを用いると CD-ROM からシステムをインストールする前に、
ディスクのパーティション分割とフォーマットが行なえます。
ただ、あまり分割を多くしすぎるとエラーが
(しかも 1 倍速の CD-ROM からのインストールが長々と続いた後に...)
起こります。
筆者は以前働いていたところで実際このような目にあい、
その時はまず一台のドライブにインストールしてから
他のドライブへ内容を移すことで回避しました。

<!--O
The default settings are sensible for most things, yet there remains a little
oddity: swap drives. Even though the official manual recommends multiple swap
drives (which are used in a similar fashion as on Linux) the default is to use
only a single drive. It is recommended to change this as soon as possible.
-->
デフォルトの設定はなかなかよくできたものですが、
スワップドライブの指定に関してはおかしなところがあります。
公式マニュアルではスワップを複数のドライブに指定することを勧めていますが
(Linux でもそうですね)、
デフォルトではひとつのドライブだけを使うようになっています。
この点は即刻改良されるべきだと思います。

<!--O
Sun OS 5 offers also a file system especially designed for temporary files,
<tt/tmpfs/. It offers significant speed improvements over <tt/ufs/ but does
not survive rebooting.
-->
Sun OS 5 は一時領域向けに特化したファイルシステム
<tt/tmpfs/ を持っています。これは <tt/ufs/ に比べてずっと高速ですが、
再起動するとデータは消えてしまいます。

<!--
This is a kind of souped up RAM disk, and like ordinary RAM disks
the contents is lost when the power goes. If space is scarce parts of the
pseudo drive is swapped out, so in effect you store temporary files on the
swap partition. Linux does not have such a file system; it has been discussed
in the past but opinions were mixed. I would be interested in hearing comments
on this. -->

<!--O
The only comment so far is: beware! Under Solaris 2.0 it seem that
creating too big files in <tt>/tmp</tt> can cause an out of swap space
kernel panic trap. As the evidence of what has happened is as lost as
any data on a RAMdisk after powering down it can be hard to find out
what has happened. What is worse, it seems that user space processes
can cause this kernel panic and unless this problem is taken care of
it is best not to use <tt/tmpfs/ in potentially hostile environments.
-->
現時点での筆者の意見は「注意せよ!」です。
Solaris 2.0 で <tt>/tmp</tt> に大きすぎるファイルを作ってしまうと、
"out of swap space" のカーネルパニックを起こすことがあります。
起こったことに関する証拠は RAM ディスクにあるので、
電源を切ったときに他のデータと一緒に失われてしまいます。
さらに悪いのは、
ユーザ空間のプロセスがこのカーネルパニックを引き起こすことが
できるらしいことです。
この問題が解決されるまでは <tt/tmpfs/ は使わないことです。
少なくとも自分の首がかかっているような環境では。

<!--O
Also see the notes on
<ref id="tmpfs"
   name="tmpfs">.
-->
<ref id="tmpfs" name="tmpfs">
にある記述も参考にしてください。
<!-- 
and
<ref id="comb-swap-n-tmp"
   name="Combining swap and /tmp">.
 -->

<!--O
Trivia: There is a movie also called Solaris, a science fiction movie that is
very, very long, slow and incomprehensible. This was often pointed out at the
time Solaris (the OS) appeared...
-->
余談: Solaris って言う映画もあります。とっても、と〜っても長くて難解な
SF 映画です。 Solaris (OS のほう) が現われたときには、
良くこの映画が引き合いに出されたものでした...

<sect1>BeOS
<p>
<nidx>disk!operating systems, other!BeOS</nidx>
<!--O
This operating system is one of the more recent one to arrive
and it features a file system that has some database like features.
-->
この OS はごく最近登場したもので、
データベースのような機能を持ったファイルシステムを備えています。

<!--O
There is a BFS file system driver being developed for Linux
and is available in alpha stage. For more information check the
<url url="http://hp.vector.co.jp/authors/VA008030/bfs/"
    name="Linux BFS page">
where patches also are available.
-->
BFS ファイルシステムの Linux ドライバも開発中で、
現在アルファの段階です。詳細な情報は
<url url="http://hp.vector.co.jp/authors/VA008030/bfs/"
    name="Linux BFS page">
にあります。パッチもここに置かれています。


<!--O
<sect>Clusters
-->
<sect>システムのクラスタ化
<p>
<nidx>disk!technologies!clusters</nidx>
<!--O
In this section I will briefly touch on the ways machines can be connected
together but this is so big a topic it could be a separate HOWTO in its
own right, hint, hint. Also, strictly speaking, this section lies outside
the scope of this HOWTO, so if you feel like getting fame etc. <em/you/ could
contact me and take over this part and turn it into a new document.
-->
この章では複数のマシンを接続して一緒に用いるやり方について
簡単に触れたいと思います。しかしこれは本来大きなテーマなので、
もしかしたら別の HOWTO に分割する方が良いかもしれません(ご意見待つ!)。
また正直なところをいいますと、
このセクションは本 HOWTO 文書の内容からは少々外れています。
有名になりたい<em/あなた/、
この文書を引き継いで新たな文書を書き起こしてみてくれませんか？
筆者まで連絡してください。

<!--O
These days computers gets outdated at an incredible rate. There is however
no reason why old hardware could not be put to good use with Linux. Using
an old and otherwise outdated computer as a network server can be both
useful in its own right as well as a valuable educational exercise. Such
a local networked cluster of computers can take on many forms but to remain
within the charter of this HOWTO I will limit myself to the disk strategies.
Nevertheless I would hope someone else could take on this topic and turn it
into a document on its own.
-->
最近では、コンピュータは恐るべきスピードで時代遅れになってしまいます。
しかし古いマシンでも Linux なら適切な用途に利用できることがあります。
少々古いコンピュータでもネットワークサーバとして有効に使うことができますし、
これは教育的にも価値があります。
このようにローカルなネットワークで接続されたコンピュータの集団は
多様な形態をとることが可能ですが、この HOWTO 文書の目的からして、
ここではディスクの管理に関してのみを述べたいと思います。
筆者は、他の人がこの問題を取り上げて
独立した文書にしてくれることを期待しています。

<!--O
This is an exciting area of activity today, and many forms of clustering
is available today, ranging from automatic workload balancing over local
network to more exotic hardware such as Scalable Coherent Interface (SCI)
which gives a tight integration of machines, effectively turning them into
a single machine. Various kinds of clustering has been available for larger
machines for some time and the VAXcluster is perhaps a well known example
of this. Clustering is done usually in order to share resources such as
disk drives, printers and terminals etc, but also processing resources equally
transparently between the computational nodes.
-->
この分野は今日活発な議論がされており、
多くの形態のクラスタ化が可能になっています。
ローカルなネットワークを介しての自動的な負荷分散がその一つですし、
Scalable Coherent Interface (SCI) といったような
まだあまり知られていないハードウェアを用いて、
複数のマシンを緊密に連携させ、
あたかも一台のマシンのようにすることもできます。
大きなマシンに関しては以前から数多くのクラスタ化が可能になっています。
有名な例としては VAXcluster などが挙げられるでしょう。
クラスタ化は通常ディスクドライブやプリンタ、
端末などの資源を共有するために行われますが、
プロセスも資源として計算機ノード間で透過的に扱うことが可能です。

<!--O
There is no universal definition of clustering, in here it is taken to mean
a network of machines that combine their resources to serve users. Admittedly
this is a rather loose definition but this will change later.
-->
クラスタ化には特に一般的な定義はありません。
ここではユーザに提供する資源を共有している複数のマシンからなる
ネットワークを考えることにしましょう。
これは少々緩い定義ですが、後に変更されて行くでしょう。

<!--O
These days also Linux offers some clustering features but for a starter
I will just describe a simple local network. It is a good way of putting old
and otherwise unusable hardware to good use, as long as they can run Linux or
something similar.
-->
最近は Linux でもクラスタ化の機能が提供されています。
しかしここではまず簡単なローカルネットの構成から説明を始めたいと思います。
古くて、他には用途の無いようなハードウェアでも、
Linux のような OS で動かせば充分役に立ちます。

<!--O
One of the best ways of using an old machine is as a network server in which
case the effective speed is more likely to be limited by network bandwidth
rather than pure computational performance. For home use you can move the
following functionality off to an older machine used as a server:
-->
古いマシンの利用法としては、ネットワークサーバ、
特に演算性能ではなくネットワークのバンド幅で律速されているようなサーバが
適しています。例えば自宅では以下のような機能を
古いマシンを使ったサーバに移動させると良いでしょう。
<!--O
<itemize>
<item>news
<item>mail
<item>web proxy
<item>printer server
<item>modem server (PPP, SLIP, FAX, Voice mail)
</itemize>
-->
<itemize>
<item>ニュース
<item>メール
<item>web のプロキシサーバ
<item>プリンタサーバ
<item>モデムサーバ (PPP, SLIP, FAX, ボイスメールなど)
</itemize>

<!--O
You can also <tt/NFS mount/ drives from the server onto your workstation
thereby reducing drive space requirements. Still read the FSSTND to see
what directories should <em/not/ be exported. The best candidates for
exporting to all machines are <tt>/usr</tt> and <tt>/var/spool</tt>
and possibly <tt>/usr/local</tt> but probably not <tt>/var/spool/lpd</tt>.
-->
ドライブを NFS サーバからマウントすれば、
ワークステーション側でディスクを節約することもできます。
どのディレクトリを<em/マウントすべきでない/かは、
やはり FSSTND を参考にしてください。
すべてのマシンで共有すべきディレクトリの候補としては
<tt>/usr</tt> と <tt>/var/spool</tt>、あるいは 
<tt>/usr/local</tt> などが挙げられます。でも例えば 
<tt>/var/spool/lpd</tt> などは共有させない方が良いでしょう。

<!--O
Most of the time even slow disks will deliver sufficient performance. On
the other hand, if you do processing directly on the disks on the server or
have very fast networking, you might want to rethink your strategy and use
faster drives. Searching features on a web server or news database searches
are two examples of this.
-->
ほとんどの場合は遅いディスクでも充分な性能が得られます。
一方サーバ上で直接ディスクを扱う必要がある場合や、
ネットワークが非常に高速な場合には、構成を考え直し、
速いディスクを使うのが良いでしょう。
例えば web サーバの検索機能や
ニュースのデータベース検索機能などが該当します。

<!--O
Such a network can be an excellent way of learning system administration
and building up your own toaster network, as it often is called. You can
get more information on this in other HOWTOs but there are two important
things you should keep in mind:
-->
このようなネットワークはシステム管理の学習にも最適で、
将来自分でネットワークを作るときに役に立ちます。
この点に関しては他の HOWTO 文書から多くの情報を得ることができるでしょう。
ただし以下のことは気に留めておいてください。
<itemize>
<!--O
<item>Do not pull IP numbers out of thin air. Configure your inside net
using IP numbers reserved for private use, and use your network server
as a router that handles this IP masquerading.
-->
<item>IP 番号のリソースは枯渇しかかっているので、できるだけ節約しましょう。
プライベートネットワーク用の IP 番号を使い、ネットワークサーバをルータにして
IP マスカレードを用いると良いでしょう。
<!--O
<item>Remember that if you additionally configure the router as a firewall
you might not be able to get to your own data from the outside, depending
on the firewall configuration.
-->
<item>ルータをファイアウォールにする場合は、
設定によっては自分自身のデータさえも
外部から閲覧できなくなる可能性があります。
</itemize>

<!--O
The <em/Nyx/ network provides an example of a cluster in the sense defined here.
It consists of the following machines:
-->
<em/Nyx/ のネットワークはここでいうところの
「クラスタ化」を実現しています。
以下のようなマシンがネットに含まれています。
<descrip>
<!--O
<tag/nyx/ is one of the two user login machines and also provides some
of the networking services.
-->
<tag/nyx/これはユーザがログインできる二台のマシンのうちのひとつです。
ネットワークサービスも提供しています。
<!--O
<tag/nox/ (aka nyx10) is the main user login machine and is also the
mail server.
-->
<tag/nox (別名 nyx10)/これはユーザが主にログインするマシンで、
メールサーバにもなっています。
<!--O
<tag/noc/ is a dedicated news server. The news spool is made accessible
through NFS mounting to nyx and nox.
-->
<tag/noc/これは専用のニュースサーバです。ニューススプールは
nyx や nox からも NFS マウントできるようになっています。
<!--O
<tag/arachne/ (aka www) is the web server. Web pages are written by
NFS mounting onto nox.
-->
<tag/arachne (別名 www)/
web サーバです。
web のページが置かれているディレクトリは nox が NFS マウントしています。
</descrip>

<!--O
There are also some more advanced clustering projects going, notably
-->
より進んだクラスタ化に関するプロジェクトも進行中です。
注目すべきものとしては以下のようなものが挙げられます。
<itemize>
<item>
<!-- <url url="http://cesdis.gsfc.nasa.gov/linux/beowulf/beowulf.html" -->
<url url="http://www.beowulf.org/"
name="The Beowulf Project">

<item>
<url url="http://www.disi.unige.it/project/gamma/"
name="The Genoa Active Message Machine (GAMMA)">

</itemize>

<p>
<!--O
High-tech clustering requires high-tech interconnect, and SCI is one of them.
To find out more you can either look up the home page of
<url url="http://www.dolphinics.no/"
name="Dolphin Interconnect Solutions">
which is one of the main actors in this field,
or you can have a look at
<url url="http://www.scizzl.com/"
name="scizzl">.
-->
クラスタ化を押し進めるには、
SCI のような進んだ技術による接続が必要になります。
より情報を求める方には、以下のページが参考になるでしょう。
<url url="http://www.dolphinics.no/"
name="Dolphin Interconnect Solutions">
この会社はこの分野における主役の一人と言えるでしょう。また
<url url="http://www.scizzl.com/"
name="scizzl">
も参考になるかもしれません。

<p>
<!--O
Centralised mail servers using IMAP are becoming more and more popular
as disks become large enough to keep all mail stored indefinitely
and also cheap enough to make it a feasible option.
Unfortunately it has become clear that <tt/NFS/ mounting the mail
archives from another machine can cause corruption of the IMAP
database as the server software does not handle NFS timeouts too well,
and NFS timeouts are a rather common occurrence.
Keep therefore the mail archive local to the IMAP server.
-->
IMAP を用いた集中型メールサーバは最近非常に増えてきています。
ディスクが充分大きくなってすべてのメールをためこんでおけるようになったため、
またディスクが安価になってこれが現実的な選択肢になってきたためでしょう。
残念なことに、メールアーカイブを他のマシンから <tt/NFS/ マウントすると、
IMAP のデータベースが破壊されてしまうことがわかっています。
サーバのソフトウェアが NFS タイムアウトをうまく扱うことができないからです
(そして NFS タイムアウトは結構な頻度で起こるものなんです)。
メールアーカイブは IMAP サーバのローカルなディスクに保存してください。

<!--O
<sect>Mount Points
-->
<sect>マウントポイント
<p>
<nidx>disk!mount points</nidx>
<!--O
In designing the disk layout it is important not to split off the
directory tree structure at the wrong points, hence this section.
As it is highly dependent on the FSSTND it has been put aside in
a separate section, and will most likely have to be totally rewritten
when FHS is adopted in a Linux distribution.
In the meanwhile this will do.
-->
レイアウトの設計作業を行なう際には、
ディレクトリのツリー構造への切れ目を間違ったところに入れないよう
注意する必要があります。
この章はそのためのガイドラインです。
この章の内容は FSSTND に大きく依存しますので、
独立させることにしました。
将来 FHS が各 Linux ディストリビューションで採用された暁には、
この章は全面的に書き直されることになるでしょう。

<!--O
Remember that this is a list of where a separation <em/can/ take place,
not where it <em/has/ to be. As always, good judgement is always required.
-->
ここで述べているのは分割が<em/してもよい/場所であって、
分割<em/すべき/場所ではありません。
適切な判断が重要です。

<!--O
Again only a rough indication can be given here. The values indicate
-->
荒っぽいですが、分割の推薦度合を数字化しておきます。
それぞれの値の意味を示します。

<!--O
<tscreen><verb>
0=don't separate here
1=not recommended
 ...
4=useful
5=recommended
</verb></tscreen>
-->
<tscreen><verb>
0=分割すべきではない
1=勧められない
…
4=分割するのは有効
5=分割すべき
</verb></tscreen>

<!--O
In order to keep the list short, the uninteresting parts are removed.
-->
リストを短くするために、重要でない部分は削除してあります。

<tscreen><verb>
Directory   Suitability
/ 
|
+-bin       0
+-boot      0
+-dev       0
+-etc       0
+-home      5
+-lib       0
+-mnt       0
+-proc      0
+-root      0
+-sbin      0
+-tmp       5
+-usr       5
| \
| +-X11R6     3
| +-bin       3
| +-lib       4
| +-local     4
| | \
| | +bin        2
| | +lib        4
| +-src       3
|
+-var       5
  \
  +-adm       0
  +-lib       2
  +-lock      1
  +-log       0
  +-preserve  1
  +-run       1
  +-spool     4
  | \
  | +-mail      3
  | +-mqueue    3
  | +-news      5
  | +-smail     3
  | +-uucp      3
  +-tmp       5
</verb></tscreen>

<!--O
There is of course plenty of adjustments possible, for instance a home user
would not bother with splitting off the <tt>/var/spool</tt> hierarchy but
a serious ISP should. The key here is <em/usage/.
-->
もちろん調整すべき点は多々あります。
例えば自宅で使っているユーザはわざわざ
<tt>/var/spool</tt> を分割する必要はないでしょうし、
逆にサービスプロバイダでは是非分割すべきでしょう。
重要なのはシステムの利用のされ方です。

<!--O
<em/QUIZ!/ Why should <tt>/etc</tt> never be on a separate partition?
Answer: Mounting instructions during boot is found in the file
<tt>/etc/fstab</tt> so if this is on a separate and unmounted partition
it is like the key to a locked drawer is inside that drawer, a hopeless
situation. (Yes, I'll do nearly anything to liven up this HOWTO.)
-->
<em/問題!/ なぜ <tt>/etc</tt> を別パーティションにしてはいけないのでしょう？
回答: ブート時のマウント動作は
<tt>/etc/fstab</tt> ファイルにある情報に従って行われます。
ですから、もしこのファイルがマウントされていない別パーティションにあると、
「引き出しのカギが引き出しの中に入っている」
のと同じ絶望的な状況になります。
(はいはい、この HOWTO を飽きずに読んでもらうためならなんでもやりますよん)


<!--O
<sect>Considerations and Dimensioning
-->
<sect>考察と分割
<p>
<nidx>disk!considerations and dimensioning</nidx>
<!--O
The starting point in this will be to consider where you are and what
you want to do. The typical home system starts out with existing
hardware and the newly converted Linux user will want to get the most
out of existing hardware. Someone setting up a new system for a
specific purpose (such as an Internet provider) will instead have to
consider what the goal is and buy accordingly. Being ambitious I will
try to cover the entire range.
-->
まず自分の置かれている立場と、何がしたいのかということから始めましょう。
家庭のシステムは既にあるハードウェアにインストールされることが多いでしょう。
新しく Linux ユーザになった人は、その既存のハードウェアから
最高のパフォーマンスを引き出したいと思うでしょう。
逆にインターネットプロバイダのように、
特定の目的のために新たなシステムをセットアップする場合は、
目的に応じて購入するハードウェアを決定する必要があります。
この文書では、この両極をカバーしたいと思っています。

<!--O
Various purposes will also have different requirements regarding file
system placement on the drives, a large multiuser machine would
probably be best off with the <tt>/home</tt> directory on a
separate disk, just to give an example.
-->
様々な目的に応じて、
ファイルシステムのドライブへの配置も異なってくるでしょう。
例えばマルチユーザで使う大きなマシンなどでは 
<tt>/home</tt> を独立したディスクに分離するのが良いでしょう。

<!--O
In general, for performance it is advantageous to split most things
over as many disks as possible but there is a limited number of
devices that can live on a SCSI bus and cost is naturally also a
factor. Equally important, file system maintenance becomes more
complicated as the number of partitions and physical drives increases.
-->
一般に性能を上げるには、
できるだけたくさんのものを別々のディスクに分散させるのが有利です。
しかし一つの SCSI バスに繋ぐことのできるデバイスの数は限られていますし、
コストの問題も絡んでくるでしょう。
またパーティションやディスクの数が増えるにつれて
管理が面倒になるという点も重要です。

<!--O
<sect1>Home Systems
-->
<sect1>自宅のシステム
<p>
<nidx>disk!considerations and dimensioning!home systems</nidx>
<!--O
With the cheap hardware available today it is possible to have
quite a big system at home that is still cheap, systems that
rival major servers of yesteryear. While many started out with
old, discarded disks to build a Linux server (which is how this
HOWTO came into existence), many can now afford to buy 40 GB
disks up front.
-->
最近の安価なハードウェアを使えば、それほどお金をかけなくても
自宅に大きなシステムを構築できるでしょう。
有名なサイトの一年前のサーバマシンと張りあえるくらいものも
それほど難しくないはずです。
多くの人が古くて余ったディスクからサーバを構築する一方
(この HOWTO が生まれるきっかけもこれでした)、
40 GB 分のディスクを買いそろえることができる人も
また少なくはないでしょう。

<!--O
Size remains important for some, and here are a few guidelines:
-->
でもサイズの見積もりが必要な人もまだいるでしょうから、
以下にいくつかの目安を挙げておきます。

<descrip>
<!--O
<tag/Testing/ Linux is simple and you don't even need a hard disk to
try it out, if you can get the boot floppies to work you are likely to
get it to work on your hardware. If the standard kernel does not work
for you, do not forget that often there can be special boot disk versions
available for unusual hardware combinations that can solve your initial
problems until you can compile your own kernel.
-->
<tag/Linux を試す/
Linux はシンプルにできていて、試すだけならハードディスクも必要ありません。
ブートフロッピーさえあれば、あなたの持っているハードウェアで
Linux を動かしてみることができます。
もし使っているハードウェアが特殊で標準のカーネルが動かない場合でも、
対応したブートディスクが用意されているはずです。
最悪の場合でも、お使いのシステムに適応したカーネルが構築できるまでの環境は
整っているはずです。

<!--O
<tag/Learning/ about operating system is something Linux excels in,
there is plenty of documentation and the source is available. A single
drive with 50 MB is enough to get you started with a shell, a few of
the most frequently used commands and utilities.
-->
<tag/Linux で学ぶ/
OS について学ぶには Linux は最適です。関連文書が山ほどありますし、
ソースを見ることもできます。
ドライブ一台に 50 MB ほどの容量があれば、シェルを起動し、
良く使われるコマンドやユーティリティを入れておくには充分でしょう。

<!--O
<tag/Hobby/ use or more serious learning requires more commands and
utilities but a single drive is still all it takes, 500 MB should give
you plenty of room, also for sources and documentation.
-->
<tag/Linux で遊ぶ/
趣味として Linux を扱ったり、学習をさらに進めるためには、
もう少し多くのコマンドやユーティリティが必要になるかもしれません。
しかしドライブは相変わらず一台、 500 MB ほどあれば OK です。
ソースやドキュメントも充分入れておけるはずです。

<!--O
<tag/Serious/ software development or just serious hobby work requires
even more space. At this stage you have probably a mail and news feed
that requires spool files and plenty of space. Separate drives for
various tasks will begin to show a benefit. At this stage you have
probably already gotten hold of a few drives too. Drive requirements
gets harder to estimate but I would expect 2-4 GB to be plenty, even
for a small server.
-->
<tag/Linux で仕事する/
プログラム開発や、趣味でも本格的な利用となると、
もう少し容量が必要になります。
この頃になるときっとメールやニュースを利用するようになっているでしょうから、
そのためのスプール領域が大量に必要になります。
各種のタスクに別々のドライブを割り当てることが有効になります。
この段階ではきっと複数のドライブを利用するようになるでしょう。
ドライブの必要量を計算するのは難しいですが、
2〜4 GB あれば良いのではないかと思います。
小規模ならサーバでもこれだけあれば大丈夫でしょう。

<!--O
<tag/Servers/ come in many flavours, ranging from mail servers to full
sized ISP servers. A base of 2 GB for the main system should be
sufficient, then add space and perhaps also drives for separate
features you will offer. Cost is the main limiting factor here
but be prepared to spend a bit if you wish to justify the "S"
in ISP. Admittedly, not all do it.
-->
<tag/Linux をサーバにする/
サーバと言ってもメールサーバからサービスプロバイダまで様々です。
メインのシステムには 2 GB あれば良いでしょう。
その後、サービスに応じて容量やドライブを足して行きます。
コストが主な制限になってくるでしょうが、
「サービス」プロバイダであり続けるためには、
ディスクを追加できるように資金には余裕を持っておくことです
(そうしていないところも多いようですが)。

<!--O
Basically a server is dimensioned like any machine for serious use
with added space for the services offered, and tends to be IO bound
rather than CPU bound.
-->
本格的に利用されるマシンは皆そうですが、
サーバも基本的には割り当てられたリソースを
一杯一杯になるまで使いきってしまうものです。
そしてサーバの場合は、 CPU よりも IO によって律速される場合が多いです。

<!--O
With cheap networking technology both for land lines as well as
through radio nets, it is quite likely that very soon home users
will have their own servers more or less permanently hooked onto
the net.
-->
有線でも無線でも、ネットワークの技術はどんどん安価になってきていますから、
これからの時代にはホームユーザーがネットにつないだサーバは、
すぐに多かれ少なかれ「つなぎっぱなし」になってしまうでしょう。
</descrip>

<!--O
<sect1>Servers
-->
<sect1>各種サーバ
<p>
<nidx>disk!servers</nidx>
<!--O
Big tasks require big drives and a separate section here. If possible
keep as much as possible on separate drives. Some of the appendices
detail the setup of a small departmental server for 10-100
users. Here I will present a few consideration for the higher end
servers. In general you should not be afraid of using RAID, not only
because it is fast and safe but also because it can make growth a
little less painful. All the notes below come as additions to the
points mentioned earlier.
-->
大きなタスクをいくつも走らせるようになると、
大きな容量のドライブが必要になり、
それぞれ専用のエリアを作らなければならなくなります。
可能ならばドライブは別々に分けましょう。
この文書の付録には小さな部門用のサーバ (ユーザ 10〜100 人) の
セットアップの詳細も付けておきました。
ここではハイエンドのサーバについての知識を述べておきます。
一般的には RAID を積極的に用いるべきです。
速度や信頼性の面だけでなく、ディスクの追加が多少楽になるからです。
ここで述べる内容は、今までに述べたことを補うものであると思って下さい。

<!--O
Popular servers rarely just happens, rather they grow over time and this
demands both generous amounts of disk space as well as a good net
connection.  In many of these cases it might be a good idea to reserve
entire SCSI drives, in singles or as arrays, for each task. This way you
can move the data should the computer fail. Note that transferring drives
across computers is not simple and might not always work, especially in the
case of IDE drives. Drive arrays require careful setup in order to
reconstruct the data correctly, so you might want to keep a paper copy of
your <tt/fstab/ file as well as a note of SCSI IDs.
-->
人気のあるサーバサイトというのはすぐに生まれるものではなく、
時間とともに成長し、
その過程でディスク容量やネットのバンド幅がだんだん必要になっていくものです。
このようなサーバを運用している場合、
それぞれのタスクで管理しているデータを丸ごと一つの SCSI ドライブ
(またはドライブアレイ) にあてがっておくのも良い考えです。
こうしておけばコンピュータ本体が故障した場合に
データを移動できるからです。
ただしドライブをコンピュータ間で移動するのはそれほど単純なことではなく、
うまく動かない可能性があることも注意しておいてください。
特に IDE の場合は問題の発生率が高くなるかもしれません。
ドライブアレイのデータを正しく再構成する際にも注意が必要です。 
<tt/fstab/ ファイルやそれぞれのドライブの SCSI ID を紙に書いて
保存しておくと良いでしょう。

<!--O
<sect2>Home Directories <label id="server-home-dirs">
-->
<sect2>ホームディレクトリ<label id="server-home-dirs">
<p>
<nidx>disk!servers!home directories</nidx>
<!--O
Estimate how many drives you will need, if this is more than 2 I would
recommend RAID, strongly. If not you should separate users across your
drives dedicated to users based on some kind of simple hashing algorithm.
For instance you could use the first 2 letters in the user name, so
<tt>jbloggs</tt> is put on <tt>/u/j/b/jbloggs</tt> where <tt>/u/j</tt>
is a symbolic link to a
physical drive so you can get a balanced load on your drives.
-->
まずドライブが何台必要かを見積もりましょう。 2 台以上ならば
RAID を使うことを強くお勧めします。 RAID を利用しない場合は、
ハッシュ的なアルゴリズムを使うなどして、
ユーザをそれぞれのドライブに振り分ける必要があります。
例えばユーザ名の最初の 2 文字などを使うと良いかもしれません。
jbloggs というユーザなら、ホームディレクトリは 
<tt>/u/j/b/jbloggs</tt> となります。
ここで <tt>/u/j</tt> は実際のドライブへのシンボリックリンクで、
各ドライブへの負荷を分散させるように定めます。

<!--O
<sect2>Anonymous FTP
-->
<sect2>アノニマス FTP
<p>
<nidx>disk!servers!FTP, anonymous</nidx>
<nidx>disk!servers!anonymous FTP</nidx>
<!--O
This is an essential service if you are serious about service. Good
servers are well maintained, documented, kept up to date, and
immensely popular no matter where in the world they are located. The
big server
<url url="ftp://ftp.funet.fi"
    name="ftp.funet.fi">
is an excellent example of this.
-->
サーバ機能でも良く利用される基本的なものです。良いサーバというものは、
良好なメンテナンスがされており、ドキュメントが整備されていて、更新が速く、
そして世界のどこにあろうが非常に有名になるものです。良い例としては、
大きなサーバである
<url url="ftp://ftp.funet.fi" name="ftp.funet.fi">
などが挙げられるでしょう。

<!--O
In general this is not a question of CPU but of network bandwidth. Size
is hard to estimate, mainly it is a question of ambition and service
attitudes. I believe the big archive at
<url url="ftp://ftp.cdrom.com"
    name="ftp.cdrom.com">
is a *BSD machine
with 50 GB disk. Also memory is important for a dedicated FTP server,
about 256 MB RAM would be sufficient for a very big server, whereas
smaller servers can get the job done well with 64 MB RAM.
Network connections would still be the most important factor.
-->
このとき問題になるのは CPU ではなく、通常はネットワークのバンド幅です。
容量を見積もるのは難しく、
どの程度の規模にするかやサービスに対する姿勢によるところが大です。例えば
<url url="ftp://ftp.cdrom.com" name="ftp.cdrom.com">
の巨大なアーカイブは、 *BSD マシンに 50 GB のディスクを付けたものです。
メモリも専用の FTP サーバには重要で、
巨大なサーバでは 256 MB は欲しいところです。
もう少し小さなサーバなら 64 MB の RAM でも充分仕事をしてくれるでしょう。
しかしネットワーク接続の問題がいずれにしても最重要でしょう。


<sect2>WWW <label id="www">
<p>
<nidx>disk!servers!WWW</nidx>
<nidx>disk!servers!World Wide Web</nidx>
<!--O
For many this is the main reason to get onto the Internet, in fact many
now seem to equate the two. In addition to being network intensive
there is also a fair bit of drive activity related to this, mainly
regarding the caches. Keeping the cache on a separate, fast drive
would be beneficial. Even better would be installing a caching proxy
server. This way you can reduce the cache size for each user and speed
up the service while at the same time cut down on the bandwidth
requirements.
-->
WWW は多くの人々にとってインターネットを利用するきっかけとなりました。
また、この 2 つを同じものとみなしている人も
この「多くの人々」の中にはいるようですね。
やはりネットワークによる影響が大ですが、ドライブの動作も
(特に Web ページのキャッシュに関して) 影響します。
キャッシュ領域は独立した速いドライブに置いておくと有利です。
キャッシュ機能込みのプロキシサーバをインストールするとさらに良いでしょう。
このようにすれば、それぞれのユーザの WWW 要求をまとめられるので、
キャッシュ領域のサイズも小さくできますし、
ネットワークのバンド幅も節約できます。

<!--O
With a caching proxy server you need a fast set of drives, RAID0 would
be ideal as reliability is not important here. Higher capacity is
better but about 2 GB should be sufficient for most. Remember to match
the cache period to the capacity and demand. Too long periods would on
the other hand be a disadvantage, if possible try to adjust based on
the URL. For more information check up on the most used servers such as
<tt/Harvest/,
<!-\- http://squid.nlanr.net/Squid -\->
<!-\- <url url="http://www.squid-cache.org/Squid" 001203 -\->
<url url="http://www.squid-cache.org/"
    name="Squid">
and the one from
<url url="http://www.netscape.com"
    name="Netscape">.
-->
キャッシュ付きのプロキシサーバには高速なドライブ (アレイ) が必要になります。
RAID 0 を利用できれば理想的です (信頼性はさほど必要ありませんから)。
大きな方が良いですが、 2 GB もあれば大抵は大丈夫でしょう。
キャッシュを保持する期間を長くするとたくさんの領域が必要になりますが、
キャッシュへのヒット率も向上します。
しかしあまり長くしすぎるのも良くありません。
できれば URL ごとに調整できると良いですね。さらに情報を求める人は、
サーバのドキュメントなどを調べてください。 <tt/Harvest/ や
<url url="http://www.squid-cache.org/"
    name="Squid">
などが有名です。
<url url="http://www.netscape.com" name="Netscape">
から出ているものもあるようです。

<!--O
<sect2>Mail
-->
<sect2>メール
<p>
<nidx>disk!servers!mail</nidx>
<!--O
Handling mail is something most machines do to some extent. The big mail
servers, however, come into a class of their own. This is a demanding task
and a big server can be slow even when connected to fast drives and a good
net feed. In the Linux world the big server at <tt/vger.rutgers.edu/ is a
well known example. Unlike a news service which is distributed and which
can partially reconstruct the spool using other machines as a feed, the
mail servers are centralised. This makes safety much more important, so for
a major server you should consider a RAID solution with emphasize on
reliability. Size is hard to estimate, it all depends on how many lists you
run as well as how many subscribers you have.
-->
メールはほとんどすべてのホストで扱われています。
しかし大きなメールサーバはメール配信機能に特化している場合が多いです。
メール配送は負荷の大きなタスクであり、
大きなサーバではドライブとネット両方が高速でもなお速度が遅い、
ということもよくあります。
Linux の世界では <tt/vger.rutgers.edu/
にある大きなサーバがよく知られている例です。
ニュースサーバでは情報が分散しているため、
他のマシンからフィードすることによってスプールを再構成できるのに対して、
メールサーバは他とデータを共有しません。
したがって安全性が非常に重要となります。
大きなサーバを運用している場合は、
信頼性を高めるために RAID の導入を考えるべきでしょう。
容量は運用しているメーリングリストの数と
購読している読者によって大きく変わります。

<!--O
Big mail servers can be IO limited in performance and for this
reason some use huge silicon disks connected to the SCSI bus to hold
all mail related files including temporary files.
For extra safety these are battery backed and filesystems
like <tt/udf/ are preferred since they always flush metadata to disk.
This added cost to performance is offset by the very fast disk.
-->
巨大なメールサーバでは、 IO が性能のボトルネックになってしまうことが
あります。このため、巨大なシリコンディスクを SCSI につないで、
そこにメール関係のファイルを、一時ファイルも含めて置いている人も
いるようです。安全性を追求するため、
これらにはバッテリーバックアップが用いられており、
また <tt/udf/ のようなファイルシステムが好まれています。
このファイルシステムは常にメタデータをディスクにフラッシュするからです。
これは性能を落としますが、非常に高速なディスクを用いることで
調整されています。

<!--O
Note that these days more and more switch over from using <tt/POP/ to
pull mail to local machine from mail server and instead use <tt/IMAP/ to
serve mail while keeping the mail archive centralised.
This means that mail is no longer spooled in its original sense but
often builds up, requiring huge disk space. Also more and more (ab)use
mail attachments to send all sorts of things across, even a small
word processor document can easily end up over 1 MB. Size your disks
generously and keep an eye on how much space is left.
-->
最近では、メールサーバから
<tt/POP/ を使ってローカルマシンにメールを移動して来るやり方に代わって、
メールアーカイブを一ヶ所に集中させておき、
<tt/IMAP/ で閲覧する手法が取られるようになってきています。
これはすなわち、メールはもはや「スプール」されるのではなく、
ひたすら大きくなりつづけることを意味します。
したがって膨大なディスク領域が必要になります。
さらに、ありとあらゆる通信に添付ファイルが頻用 (濫用) されるようになりました。
小さなワープロ文書ですら 1 MB を越えることが珍しくありません。
ディスクは気前良く用意し、残りの容量に目を光らせましょう。

<!--O
<sect2>News
-->
<sect2>ニュース
<p>
<nidx>disk!servers!news</nidx>
<!--O
This is definitely a high volume task, and very dependent on what
news groups you subscribe to. On Nyx there is a fairly complete feed
and the spool files consume about 17 GB. The biggest groups are no doubt
in the <tt>alt.binary.*</tt> hierarchy, so if you for some reason decide not to
get these you can get a good service with perhaps 12 GB. Still others,
that shall remain nameless, feel 2 GB is sufficient to claim ISP status.
In this case news expires so fast I feel the spelling IsP is barely
justified. A full newsfeed means a traffic of a few GB every day and this
is an ever growing number.
-->
ニュースは必要な領域が大きいですが、
どの程度になるかは購読しているニュースグループに大きく依存します。
nyx ではほとんどすべてのグループを購読しており、 17 GB 程度を消費しています。
もっとも大きくなるのは明らかに alt.binary.* 以下のグループです。
もしこのグループを購読しなければ 12 GB 程度で良いサービスを提供できます。
小規模なところには 2 GB 程度で
「サービスプロバイダ」と称しているところもあるようですが、
この程度では expire が非常に早くなってしまうでしょう。
こういうところは「サービス」の名に値しないと言うのが筆者の意見です。
ニュースのフルフィードは毎日数 GB のトラフィックを意味します。
またこの値は大きくなり続けています。


<!--O
<sect2>Others
-->
<sect2>その他
<p>
<nidx>disk!servers!other</nidx>
<!--O
There are many services available on the net and even though many have been
put somewhat in the shadows by the web. Nevertheless, services like
<em/archie/, <em/gopher/ and <em/wais/ just to name a few, still exist and
remain valuable tools on the net. If you are serious about starting a major
server you should also consider these services. Determining the required
volumes is hard, it all depends on popularity and demand. Providing good
service inevitably has its costs, disk space is just one of them.
-->
ネットで利用できるサービスは非常に多くの種類がありますが、
その多くは WWW の影に隠れています。
しかし <em/archie/ や <em/gopher/, <em/wais/ 
と言ったサービスはまだまだ現役かつ有益なツールです。
もし手元で大きなサーバを立ち上げるつもりでしたら、
これらのサービスについても考えるべきでしょう。
必要な容量を決定するのは難しく、人気と要求頻度に依存します。
よいサービスを提供するには当然コストが必要で、
ディスク容量はその一つに過ぎません。


<!--O
<sect2>Server Recommendations
-->
<sect2>サーバ向けのお勧め
<p>
<nidx>disk!servers!recommendations</nidx>
<!--O
Servers today require large numbers of large disks to function
satisfactorily in commercial settings. As mean time between failure
(MTBF) decreases rapidly as the number of components increase it is
advisable to look into using RAID for protection and use a number of
medium sized drives rather than one single huge disk. Also look into
the High Availability (HA) project for more information.
More information is available at
 
<!-\- <url url="http://metalab.unc.edu/pub/Linux/ALPHA/linux-ha/High-Availability-HOWTO.html" 001203 -\->
<url url="http://www.ibiblio.org/pub/Linux/ALPHA/linux-ha/High-Availability-HOWTO.html"
    name="High Availability HOWTO">
and also at related
<url url="http://www.henge.com/&tilde;alanr/ha/index.html"
    name="web pages">.
-->
こんにち商用サーバに満足いく機能を発揮させるためには、
大容量のディスクを多数用いる必要があります。
用いる要素部品が増えるほど平均故障時間 (mean time between failure:
MTBF) は急激に短くなりますから、
データを守るために RAID を用いることを考えるべきだと思います。
また巨大な一台のディスクの代わりに、
やや小さい容量のドライブを複数用いることも考慮の価値があります。
より詳しい情報は High Availability (HA) プロジェクトを見てみましょう。

<url url="http://www.ibiblio.org/pub/Linux/ALPHA/linux-ha/High-Availability-HOWTO.html"
    name="High Availability HOWTO">
や、関連
<url url="http://www.henge.com/&tilde;alanr/ha/index.html"
    name="web ページ">
に、詳しい情報があります。

<!--O
There is also an article in Byte called
<url url="http://www.byte.com/columns/servinglinux/1999/06/0607servinglinux.html"
    name="How Big Does Your Unix Server Have To Be?">
with many points that are relevant to Linux.
-->
Byte にも
<url url="http://www.byte.com/columns/servinglinux/1999/06/0607servinglinux.html"
    name="How Big Does Your Unix Server Have To Be?">
という記事があります。 Linux に関連する点も多いです。


<!--O
<sect1>Pitfalls<label id="pitfalls">
-->
<sect1>落とし穴<label id="pitfalls">
<p>
<nidx>disk!pitfalls</nidx>
<!--O
The dangers of splitting up everything into separate partitions are
briefly mentioned in the section about volume management. Still, several
people have asked me to emphasize this point more strongly: when one
partition fills up it cannot grow any further, no matter if there is
plenty of space in other partitions.
-->
可能なものすべてを別々のパーティションに分けてしまうことに伴う危険性については、
ボリューム管理の節において簡単に紹介しました。
しかしこの点はより強調しておくべきだというアドバイスが多かったので、
もう一度言います:
一度設定したパーティションは使い切ったらそれで終わりで、
増やすことはできません。他のパーティションがいくら余っていてもです。

<!--O
In particular look out for explosive growth in the news spool
(<tt>/var/spool/news</tt>). For multi user machines with quotas keep
an eye on <tt>/tmp</tt> and <tt>/var/tmp</tt> as some people try to hide their
files there, just look out for filenames ending in gif or jpeg...
-->
特にニューススプール (<tt>/var/spool/news</tt>) は
爆発的に増えることがあるので注意が必要です。
quota を利用したマルチユーザのマシンでは、 
<tt>/tmp</tt> や <tt>/var/tmp</tt> にも目を配り、
ここにファイルを隠すユーザがいないかどうかも気をつけましょう
(特に <tt/.gif/ や <tt/.jpeg/ で終わる名前のファイルなど :-)。

<!--O
In fact, for single physical drives this scheme offers very little gains
at all, other than making file growth monitoring easier
(using '<tt>df</tt>') and physical track positioning. Most importantly
there is no scope for parallel disk access. A freely available volume
management system would solve this but this is still some time in the
future. However, when more specialised file systems become available
even a single disk could benefit from being divided into several
partitions.
-->
実際のところドライブがひとつしかないようなシステムでは
パーティション分割はあまり役に立ちません。
メリットは <tt/df/ を使ってファイルサイズのモニタが簡単にできること、
物理的なセクタ配置を行えることくらいでしょうか。
致命的なのはディスクの並列利用ができないことです。
フリーで使えるようなボリューム管理システムが出てくれば
この節の最初で述べた問題は解決しますが、
これはもう少し先のことになりそうです。
いろいろな機能に特化したファイルシステムが出てくれば、
1 ドライブのシステムにおいてもパーティション分割は有効になるでしょう。

<!--O
For more information see section <ref id="troubleshooting" name="Troubleshooting">.
-->
より詳しい情報は
<ref id="troubleshooting" name="トラブルシュート">.
の章を見てください。

<!-- <**** expand here (2) &&&> -->


<!--O
<sect>Disk Layout <label id="disk-layout">
-->
<sect>ディスクのレイアウト
<p>
<nidx>disk!disk layout</nidx>
<nidx>disk!layout, disk</nidx>
<!--O
With all this in mind we are now ready to embark on the layout. I
have based this on my own method developed when I got hold of 3 old
SCSI disks and boggled over the possibilities.
-->
さてさて、これまで述べてきたような知識をもとにして、
いよいよ実際のレイアウトについて述べることにしましょう。
以下の方法は私が 3 台の古いSCSI ディスクを使って、
いろいろな可能性を試しながら作り出してきたものです。

<!--O
The tables in the appendices are designed to simplify the mapping process. They
have been designed to help you go through the process of optimizations as well
as making an useful log in case of system repair. A few examples are also given.
-->
付録の表は、このマッピングの過程を簡単にするためにデザインされました。
最適化のプロセスをすすめていく作業の助けになるでしょうし、
システムを改善する時にも有用な記録となってくれるでしょう。
いくつかの例も同時に載せてあります。

<!--
At the end of this document there is an appendix with a few blank forms
that you can fill in to help you decide and design your system. The
following few paragraphs will refer to them.
-->

<!--O
<sect1>Selection for Partitioning
-->
<sect1>パーティションの選択
<p>
<nidx>disk!layout, disk!partitioning</nidx>
<!--O
Determine your needs and set up a list of all the parts of the file system
you want to be on separate partitions and sort them in descending order of
speed requirement and how much space you want to give each partition.
-->
必要な機能を決め、
別々のパーティションに分けるファイルシステムのリストを作ります。
それを必要とされる速度の順に並べ、
それぞれのパーティションに割り当てる容量を決めます。

<!--O
The table in <ref id="app-a" name="Appendix A"> section
is a useful tool to select what directories you
should put on different partitions. It is sorted in a logical order
with space for your own additions and notes about mounting points and
additional systems. It is therefore NOT sorted in order of speed, instead
the speed requirements are indicated by bullets ('o').
-->
<ref id="app-a" name="付録 A"> の表が役に立つでしょう。
この表には論理ディレクトリが順に並べてあり、
マウントポイントに関するメモや別の
OS に使う領域を書き込む部分が確保してあります。
この表は速度順には並んで<em/いません/。
代わりに必要とされる速度を 'o' の数で示してあります。

<!--O
If you plan to RAID make a note of the disks you want to use and what
partitions you want to RAID. Remember various RAID solutions offers
different speeds and degrees of reliability.
-->
RAID を利用するのでしたら、どのディスクを使って、
どのパーティションを RAID 化するかを決めておきましょう。
RAID には色々な種類があり、
様々な速度／信頼性が選択できることを頭に入れておきましょう。

<!--O
(Just to make it simple I'll assume we have a set of identical SCSI disks
and no RAID)
-->
(以下では話を簡単にするために、
同じ SCSI ディスクがいくつかある場合を考えましょう。
RAID は使わないものとします)


<!--O
<sect1>Mapping Partitions to Drives
-->
<sect1>パーティションとドライブのマッピング
<p>
<nidx>disk!layout, disk!mapping partitions</nidx>
<nidx>disk!layout, disk!partitions, mapping</nidx>
<!--O
Then we want to place the partitions onto physical disks. The point of the
following algorithm is to maximise parallelizing and bus capacity. In this
example the drives are A, B and C and the partitions are 987654321 where 9
is the partition with the highest speed requirement. Starting at one drive
we 'meander' the partition line over and over the drives in this way:
-->
次の段階では、パーティションをディスクに割り当てていきます。
これから述べるアルゴリズムのポイントは、
並列性を最大限確保してバスの容量をめいっぱい使うようにすることです。
例として、ドライブ A B C に対してパーティション
987654321 を割り当てることを考えます。
9 が最も高速性が要求されるパーティションです。
一つめのドライブから出発して、
パーティションのラインを「くねらせて」いきます。
こんな感じです。

<tscreen><verb>
	A : 9 4 3
	B : 8 5 2
	C : 7 6 1
</verb></tscreen>

<!--O
This makes the 'sum of speed requirements' the most equal across each
drive.
-->
これで高速性の要求量に対する重みが、
どのドライブでも同じくらいになります。

<!--O
Use the table in <ref id="app-b" name="Appendix B"> section
to select what drives to use for each partition in order to optimize for paralellicity.
-->
<ref id="app-b" name="付録 B"> につけた表を使って、
どのドライブのどのパーティションを用いるかを選んでください。
並列性が最高になるようにしましょう。

<!--O
Note the speed characteristics of your drives and note each directory under
the appropriate column. Be prepared to shuffle directories, partitions
and drives around a few times before you are satisfied.
-->
持っているドライブの速度の特性と、
それぞれのディレクトリを適当な列に記入してください。
ディレクトリやパーティション、ドライブは何回か入れ替えたくなるでしょうから、
表はその分用意しておきましょう。

<!--O
<sect1>Sorting Partitions on Drives
-->
<sect1>ドライブ上でパーティションを並べ替える
<p>
<nidx>disk!layout, disk!sorting partitions</nidx>
<nidx>disk!layout, disk!partitions, sorting</nidx>
<!--O
After that it is recommended to select partition numbering for each drive.
-->
以上ができたら、
それぞれのドライブでパーティションの番号づけを行いましょう。

<!--O
Use the table in <ref id="app-c" name="Appendix C"> section
to select partition numbers in order to optimize for track characteristics.
At the end of this you should have a table sorted in ascending partition
number. Fill these numbers back into the tables in appendix A and B.
-->
<ref id="app-c" name="付録 C"> の表を用いて、
パーティションの順番を決めてください。
トラックの特性が生かされるようにしましょう。
全部できたら、表をパーティション番号の昇順に並べ替えましょう。
これらの番号を付録 A や B の表に書き戻してください。

<!--O
You will find these tables useful
when running the partitioning program (<tt>fdisk</tt> or
<tt>cfdisk</tt>) and when doing the installation.
-->
<tt/fdisk/ や <tt/cfdisk/ などのパーティション分割プログラムを使うときや
インストール作業を行うときに、これらの表を参考にすると良いでしょう。

<!--O
<sect1>Optimizing
-->
<sect1>最適化
<p>
<nidx>disk!layout, disk!optimizing partitions</nidx>
<nidx>disk!layout, disk!partitions, optimizing</nidx>
<!--O
After this there are usually a few partitions that have to be 'shuffled' over
the drives either to make them fit or if there are special considerations
regarding speed, reliability, special file systems etc. Nevertheless this
gives what this author believes is a good starting point for the complete
setup of the drives and the partitions. In the end it is actual use that will
determine the real needs after we have made so many assumptions. After
commencing operations one should assume a time comes when a repartitioning
will be beneficial.
-->
上の手続きの後、通常いくつかのパーティションは入れ替える必要があります。
大きさを合わせたり、速度、信頼性、
その他ファイルシステム特有の問題などを解決するためです。
しかしそれでもここで与えた方法は
ドライブとパーティションを最適に設定するための良い出発点になります
(と筆者は信じています)。
何が必要とされるかについてを色々と考えてきたわけですが、
本当のところは実際にシステムを運用してみないと解らないでしょう。
実際に運用を始めたのち、
パーティションの切り直しが必要とされるような時期が
いつかはやって来ると思っていたほうが良いでしょう。

<!--O
For instance if one of the 3 drives in the above mentioned example is
very slow compared to the two others a better plan would be as
follows:
-->
例えば上で用いた 3 台のドライブのうち、
一つが他に比べて非常に遅いような場合には、
最適な配置は以下のようになるでしょう。

<tscreen><verb>
        A : 9 6 5
        B : 8 7 4
        C : 3 2 1
</verb></tscreen>


<!--O
<sect2>Optimizing by Characteristics
-->
<sect2>特性による最適化
<p>
<nidx>disk!layout, disk!optimizing by characteristics</nidx>
<nidx>disk!layout, disk!characteristics, optimizing by</nidx>
<!--O
Often drives can be similar in apparent overall speed but some
advantage can be gained by matching drives to the file size
distribution and frequency of access. Thus binaries are suited
to drives with fast access that offer command queueing, and
libraries are better suited to drives with larger transfer speeds
where IDE offers good performance for the money.
-->
総合的なスピードが似たようなドライブでも、
ファイルのサイズやアクセスの頻度などによって相性の良い悪いがあるものです。
たとえばバイナリの置かれているディレクトリは
コマンドキューが機能するようなアクセスの速いドライブに向いていますし、
ライブラリのディレクトリには転送速度が大きいドライブが良いでしょう。
後者に対しては IDE ディスクのコストパフォーマンスが高いかもしれません。


<!--O
<sect2>Optimizing by Drive Parallelising <label id="opt-drive-parall">
-->
<sect2>ドライブの並列化による最適化<label id="opt-drive-parall">
<p>
<nidx>disk!layout, disk!optimizing by parallelising</nidx>
<nidx>disk!layout, disk!parallelising, optimizing by</nidx>
<!--O
Avoid drive contention by looking at tasks: for instance if you are
accessing <tt>/usr/local/bin</tt> chances are you will soon also need files
from <tt>/usr/local/lib</tt> so placing these at separate drives allows less
seeking and possible parallel operation and drive caching. It is
quite possible that choosing what may appear less than ideal drive
characteristics will still be advantageous if you can gain parallel
operations. Identify common tasks, what partitions they use and try
to keep these on separate physical drives.
-->
タスクを実行するときに、ドライブ利用の競合が起こらないようにしましょう。
たとえば <tt>/usr/local/bin</tt> にアクセスした直後に
<tt>/usr/local/lib</tt> のファイルが必要になるような場合、
これらのディレクトリを別々のドライブに置いておけば、シークや読み込み、
キャッシュなどの並列化・高速化が期待できるでしょう。
並列動作が期待できる場合には、先に述べたような最適化がなされている場合よりも
優れた性能が得られることは充分ありえます。
よく行われるタスクでどのパーティションが同時に使われるかを考え、
それらを別々のディスクに置くようにしましょう。

<!--O
Just to illustrate my point I will give a few examples of
task analysis here.
-->
いまの内容をもう少し詳しく述べましょう。
以下にタスク状況の解析例をいくつか示します。

<descrip>

<!--O
<tag/Office software/ such as editing, word processing and
spreadsheets are typical examples of low intensity software both in
terms of CPU and disk intensity. However, should you have a single
server for a huge number of users you should not forget that most such
software have auto save facilities which cause extra traffic, usually
on the home directories. Splitting users over several drives would
reduce contention.
-->
<tag/Office ソフト/
エディタやワードプロセッサ、スプレッドシートなどが典型的な例です。
CPU の負荷もディスクの負荷もそれほど高くありません。
しかし、大量のユーザを抱えているサーバなどを管理している場合には、
これらのソフトのオートセーブ機能についてしっかり認識しておきましょう。
この機能はホームディレクトリに余分なトラフィックを生じることになります。
ユーザのホームディレクトリをいくつかのドライブに分散させておけば
負荷の集中を減らすことができます。

<!--O
<tag/News/ readers also feature auto save features on home directories
so ISPs should consider separating home directories
-->
<tag/ニュース/
ニュースリーダもホームディレクトリへのオートセーブを行なうので、
サービスプロバイダならばホームディレクトリを
別のドライブに分ける方が良いでしょう。

<!--O
News spools are notorious for their deeply nested directories and
their large number of very small files. Loss of a news spool
partition is not a big problem for most people, too, so they are good
candidates for a RAID 0 setup with many small disks to distribute
the many seeks among multiple spindles. It is recommended in the
manuals and FAQs for the INN news server to put news spool
and <tt>.overview</tt> files on separate drives for larger installations.
-->
ニューススプールはディレクトリ構造がとても深くなり、
小さなファイルがとてもたくさん置かれます。
ニューススプールパーティションが失われても
大部分の人には大きな問題ではないでしょうから、
小さなディスクをたくさん集めて RAID 0 の構成にし、
シーク動作をたくさんのスピンドルに分散させると良いかもしれません。
また INN ニュースサーバのマニュアルや FAQ で推奨されていることですが、
大きなニュースサイトではニューススプールと <tt>.overview</tt>
ファイルを別のドライブに置いておくのが良いそうです。

<!-- There is also a web page dedicated to          001210 gone.
<url url="http://www.spinne.com/usenet/inn-perf.html"
    name="INN optimising">
well worth reading. -->
-->

<!--O
<tag/Database/ applications can be demanding both in terms of drive
usage and speed requirements. The details are naturally application
specific, read the documentation carefully with disk requirements in
mind. Also consider RAID both for performance and reliability.
-->
<tag/データベース/
データベースアプリケーションはドライブの容量と速度を両方とも必要とします。
詳細はもちろんアプリケーションによります。
ドキュメントを読むときにディスクの必要量に注意しておきましょう。
性能や信頼性を高めるためには
RAID を導入するのも良いでしょう。

<!--O
<tag/E-mail/ reading and sending involves home directories as well as
in- and outgoing spool files. If possible keep home directories and
spool files on separate drives. If you are a mail server or a mail hub
consider putting in- and outgoing spool directories on separate
drives.
-->
<tag/電子メール/
メールの送受信にはホームディレクトリと
到着用／発信用のスプールが使われることになります。
可能ならばホームディレクトリとスプールは
別のドライブに分けておくべきでしょう。メールサーバ (メールハブ) では、
到着用と発信用のスプールも別のドライブに分けると良いかもしれません。

<!--O
Losing mail is an extremely bad thing, if you are managing an ISP or major
hub. Think about RAIDing your mail spool and consider frequent
backups.
-->
もしあなたが ISP やメジャーなメールハブマシンを管理しているとしたら、
メールを失うのはもう最悪です。
メールスプールを RAID 化すること、
頻繁にバックアップを取ることを考えましょう。

<!--O
<tag/Software development/ can require a large number of directories
for binaries, libraries, include files as well as source and project
files. If possible split as much as possible across separate
drives. On small systems you can place <tt>/usr/src</tt> and project files on
the same drive as the home directories.
-->
<tag/プログラム開発/
たくさんのディレクトリが必要になります。コンパイラのバイナリやライブラリ、
インクルードファイル、さらにはソースやプロジェクトファイルなどなど。
許す限り別々のドライブに分けておきましょう。
小さなシステムでは <tt>/usr/src</tt> とプロジェクトファイルをホームディ
レクトリと一緒のドライブに入れてしまっても良いかもしれません。

<!--O
<tag/Web browsing/ is becoming more and more popular. Many browsers
have a local cache which can expand to rather large volumes. As this
is used when reloading pages or returning to the previous page, speed
is quite important here. If however you are connected via a well configured
proxy server you do not need more than typically a few megabytes per
user for a session.
See also the sections on
<ref id="server-home-dirs" name="Home Directories">
and
<ref id="www" name="WWW">.
-->
<tag/Web ブラウザ/
WWW は人気が増す一方ですね。多くのブラウザではローカルなキャッシュを用
いており、これらはかなりの大きさになることがあります。
ローカルキャッシュは以前に読んだことのあるページを再ロードしたり、
直前のページに戻ったりするときに用いられますので、
この領域の速度はとても重要です。
しかしちゃんと設定されたプロキシサーバを経由している場合なら、
各ユーザ、各セッションにつき数 MB 程度あれば充分でしょう。
<ref id="server-home-dirs" name="ホームディレクトリ">
や
<ref id="www" name="WWW">
の節も参考にしてください。

</descrip>

<!-- 990124 moved over to recommendation section
<sect1>Usage Requirements
<p>
<nidx>disk!usage requirements</nidx>
When you get a box of 10 or so CD-ROMs with a Linux distribution and
the entire contents of the big FTP sites it can be tempting to install
as much as your drives can take. Soon, however, one would find that
this leaves little room to grow and that it is easy to bite over more
than can be chewed, at least in polite company. Therefore I will make
a few comments on a few points to keep in mind when you plan out your
system. Comments here are actively sought.

<descrip>

<tag/Testing/ Linux is simple and you don't even need a hard disk to
try it out, if you can get the boot floppies to work you are likely to
get it to work on your hardware. If the standard kernel does not work
for you, do not forget that often there can be special boot disk versions
available for unusual hardware combinations that can solve your initial
problems until you can compile your own kernel.

<tag/Learning/ about operating system is something Linux excels in,
there is plenty of documentation and the source is available. A single
drive with 50 MB is enough to get you started with a shell, a few of
the most frequently used commands and utilities.

<tag/Hobby/ use or more serious learning requires more commands and
utilities but a single drive is still all it takes, 500 MB should give
you plenty of room, also for sources and documentation.

<tag/Serious/ software development or just serious hobby work requires
even more space. At this stage you have probably a mail and news feed
that requires spool files and plenty of space. Separate drives for
various tasks will begin to show a benefit. At this stage you have
probably already gotten hold of a few drives too. Drive requirements
gets harder to estimate but I would expect 2-4 GB to be plenty, even
for a small server.

<tag/Servers/ come in many flavours, ranging from mail servers to full
sized ISP servers. A base of 2 GB for the main system should be
sufficient, then add space and perhaps also drives for separate
features you will offer. Cost is the main limiting factor here
but be prepared to spend a bit if you wish to justify the "S"
in ISP. Admittedly, not all do it.

</descrip>


<sect1>Servers
<p>
<nidx>disk!servers</nidx>
Big tasks require big drives and a separate section here. If possible
keep as much as possible on separate drives. Some of the appendices
detail the setup of a small departmental server for 10-100
users. Here I will present a few consideration for the higher end
servers. In general you should not be afraid of using RAID, not only
because it is fast and safe but also because it can make growth a
little less painful. All the notes below come as additions to the
points mentioned earlier.

Popular servers rarely just happens, rather they grow over time and this
demands both generous amounts of disk space as well as a good net
connection.  In many of these cases it might be a good idea to reserve
entire SCSI drives, in singles or as arrays, for each task. This way you
can move the data should the computer fail. Note that transferring drives
across computers is not simple and might not always work, especially in the
case of IDE drives. Drive arrays require careful setup in order to
reconstruct the data correctly, so you might want to keep a paper copy of
your <tt/fstab/ file as well as a note of SCSI IDs.

<sect2>Home Directories <label id="server-home-dirs">
<p>
<nidx>disk!servers!home directories</nidx>
Estimate how many drives you will need, if this is more than 2 I would
recommend RAID, strongly. If not you should separate users across your
drives dedicated to users based on some kind of simple hashing algorithm.
For instance you could use the first 2 letters in the user name, so
<tt>jbloggs</tt> is put on <tt>/u/j/b/jbloggs</tt> where <tt>/u/j</tt>
is a symbolic link to a
physical drive so you can get a balanced load on your drives.

<sect2>Anonymous FTP
<p>
<nidx>disk!servers!FTP, anonymous</nidx>
<nidx>disk!servers!anonymous FTP</nidx>
This is an essential service if you are serious about service. Good
servers are well maintained, documented, kept up to date, and
immensely popular no matter where in the world they are located. The
big server
<url url="ftp://ftp.funet.fi"
    name="ftp.funet.fi">
is an excellent example of this.

In general this is not a question of CPU but of network bandwidth. Size
is hard to estimate, mainly it is a question of ambition and service
attitudes. I believe the big archive at
<url url="ftp://ftp.cdrom.com"
    name="ftp.cdrom.com">
is a *BSD machine
with 50 GB disk. Also memory is important for a dedicated FTP server,
about 256 MB RAM would be sufficient for a very big server, whereas
smaller servers can get the job done well with 64 MB RAM.
Network connections would still be the most important factor.

<sect2>WWW <label id="www">
<p>
<nidx>disk!servers!WWW</nidx>
<nidx>disk!servers!World Wide Web</nidx>
For many this is the main reason to get onto the Internet, in fact many
now seem to equate the two. In addition to being network intensive
there is also a fair bit of drive activity related to this, mainly
regarding the caches. Keeping the cache on a separate, fast drive
would be beneficial. Even better would be installing a caching proxy
server. This way you can reduce the cache size for each user and speed
up the service while at the same time cut down on the bandwidth
requirements.

With a caching proxy server you need a fast set of drives, RAID0 would
be ideal as reliability is not important here. Higher capacity is
better but about 2 GB should be sufficient for most. Remember to match
the cache period to the capacity and demand. Too long periods would on
the other hand be a disadvantage, if possible try to adjust based on
the URL. For more information check up on the most used servers such as
<tt/Harvest/,
<url url="http://www.nlanr.net/Squid"
    name="Squid">
and the one from
<url url="http://www.netscape.com"
    name="Netscape">.

<sect2>Mail
<p>
<nidx>disk!servers!mail</nidx>
Handling mail is something most machines do to some extent. The big mail
servers, however, come into a class of their own. This is a demanding task
and a big server can be slow even when connected to fast drives and a good
net feed. In the Linux world the big server at <tt/vger.rutgers.edu/ is a
well known example. Unlike a news service which is distributed and which
can partially reconstruct the spool using other machines as a feed, the
mail servers are centralised. This makes safety much more important, so for
a major server you should consider a RAID solution with emphasize on
reliability. Size is hard to estimate, it all depends on how many lists you
run as well as how many subscribers you have.

<sect2>News
<p>
<nidx>disk!servers!news</nidx>
This is definitely a high volume task, and very dependent on what
news groups you subscribe to. On Nyx there is a fairly complete feed
and the spool files consume about 17 GB. The biggest groups are no doubt
in the <tt>alt.binary.*</tt> hierarchy, so if you for some reason decide not to
get these you can get a good service with perhaps 12 GB. Still others,
that shall remain nameless, feel 2 GB is sufficient to claim ISP status.
In this case news expires so fast I feel the spelling IsP is barely
justified. A full newsfeed means a traffic of a few GB every day and this
is an ever growing number.

<sect2>Others
<p>
<nidx>disk!servers!other</nidx>
There are many services available on the net and even though many have been
put somewhat in the shadows by the web. Nevertheless, services like
<em/archie/, <em/gopher/ and <em/wais/ just to name a few, still exist and
remain valuable tools on the net. If you are serious about starting a major
server you should also consider these services. Determining the required
volumes is hard, it all depends on popularity and demand. Providing good
service inevitably has its costs, disk space is just one of them.

<sect1>Pitfalls
<p>
<nidx>disk!pitfalls</nidx>
The dangers of splitting up everything into separate partitions are
briefly mentioned in the section about volume management. Still, several
people have asked me to emphasize this point more strongly: when one
partition fills up it cannot grow any further, no matter if there is
plenty of space in other partitions.

In particular look out for explosive growth in the news spool
(<tt>/var/spool/news</tt>). For multi user machines with quotas keep
an eye on <tt>/tmp</tt> and <tt>/var/tmp</tt> as some people try to hide their
files there, just look out for filenames ending in gif or jpeg...

In fact, for single physical drives this scheme offers very little gains
at all, other than making file growth monitoring easier
(using '<tt>df</tt>') and physical track positioning. Most importantly
there is no scope for parallel disk access. A freely available volume
management system would solve this but this is still some time in the
future. However, when more specialised file systems become available
even a single disk could benefit from being divided into several
partitions.
 -->

<!--O
<sect1>Compromises
-->
<sect1>妥協的手法
<p>
<nidx>disk!compromises</nidx>
<!--O
One way to avoid the aforementioned 
<ref id="pitfalls" name="pitfalls">
is to only set off fixed
partitions to directories with a fairly well known size such as swap,
<tt>/tmp</tt> and <tt>/var/tmp</tt> and group together the remainders
into the remaining partitions using symbolic links.
-->
先に述べた
<ref id="pitfalls" name="落とし穴">
を避ける方法としては以下のようなものがあります。
スワップや <tt>/tmp</tt>, <tt>/var/tmp</tt> のように
比較的サイズが分かっているようなディレクトリにだけ
それぞれパーティションをあてがい、
他のものは残ったパーティションにシンボリックリンクを使って割り振る方法です。
<!--CC pitfall へのリンク？ -->

<!--O
Example: a slow disk (<tt>slowdisk</tt>),
a fast disk (<tt>fastdisk</tt>) and an
assortment of files. Having set up <tt/swap/ and <tt/tmp/ on <tt/fastdisk/;
and <tt>/home</tt> and root on slowdisk we have (the fictitious) directories
<tt>/a/slow</tt>, <tt>/a/fast</tt>, <tt>/b/slow</tt> and <tt>/b/fast</tt>
left to allocate on the partitions
<tt>/mnt.slowdisk</tt> and <tt>/mnt.fastdisk</tt> which represents the
remaining partitions of the two drives.
-->
例を示しましょう。遅いディスクと速いディスクがあり、
この中に一揃いのシステムを詰め込むことを考えます。
スワップと <tt>/tmp</tt> は速いディスクに置き、
<tt>/home</tt> と <tt>/root</tt> は遅いディスクへ置きます。
この作業の後に残ったディレクトリを仮に <tt>/a/slow</tt>,
<tt>/a/fast</tt>, <tt>/b/slow</tt>, <tt>/b/fast</tt> としましょう。
そして各ドライブの残ったパーティションに対して
これらのディレクトリを割り振ることを考えます。

<!--O
Putting <tt>/a</tt> or <tt>/b</tt> directly on either drive gives the same
properties to the subdirectories. We could make all 4 directories
separate partitions but would lose some flexibility in managing
the size of each directory. A better solution is to make
these 4 directories symbolic links to appropriate directories on
the respective drives.
-->
<tt>/a</tt> と <tt>/b</tt> をそれぞれのドライブにあてがってしまうと、
サブディレクトリに同じ性能が与えられてしまいます。
4 つのディレクトリをそれぞれ別のパーティションに分けると、
今度は容量に対する柔軟性が失われてしてしまいます。

<!--O
Thus we make 
-->
より良い解法はこれら 4 つのディレクトリを
それぞれに適したドライブのディレクトリに対する
シンボリックリンクとすることです。

具体的には以下のようにします。ここで
<tt>/mnt.fastdisk</tt> に速いディスクの残りパーティションを、
<tt>/mnt.slowdisk</tt> に遅いデスクの残りパーティションを
マウントしているものと考えてください。

<!--O
<tscreen><verb>
/a/fast point to /mnt.fastdisk/a/fast   or   /mnt.fastdisk/a.fast
/a/slow point to /mnt.slowdisk/a/slow   or   /mnt.slowdisk/a.slow
/b/fast point to /mnt.fastdisk/b/fast   or   /mnt.fastdisk/b.fast
/b/slow point to /mnt.slowdisk/b/slow   or   /mnt.slowdisk/b.slow
</verb></tscreen>
-->
<tscreen><verb>
/a/fast は /mnt.fastdisk/a/fast または /mnt.fastdisk/a.fast へリンク
/a/slow は /mnt.slowdisk/a/slow または /mnt.slowdisk/a.slow へリンク
/b/fast は /mnt.fastdisk/b/fast または /mnt.fastdisk/b.fast へリンク
/b/slow は /mnt.slowdisk/b/slow または /mnt.slowdisk/b.slow へリンク
</verb></tscreen>

<!--O
and we get all fast directories on the fast drive without having to
set up a partition for all 4 directories. The second (right hand)
alternative gives us a flatter files system which in this case can
make it simpler to keep an overview of the structure.
-->
こうすればスピードが必要なディレクトリは速いディレクトリへおくことができ、
しかもパーティションを 4 つに分割する必要もなくなります。
リンク先として右側のような表現を利用すれば
ファイルシステムの無駄な階層化を防ぐことができ、
ディレクトリ構造が見やすくなるでしょう。

<!--O
The disadvantage is that it is a complicated scheme to set up and plan
in the first place and that all mount points and partitions have to be
defined before the system installation.
-->
この方法の欠点はごちゃごちゃしすぎているため、
初期段階での計画やセットアップには向かないことです。
またシステムのインストール前に
すべてのマウントポイントとパーティションを決めておかなければならないことも
問題かもしれません。

<!--O
<em/Important:/ note that the <tt>/usr</tt> partition must be mounted
directly onto root and not via an indirect link as described above.
The reason for this are the long backward links used extensively in
X11 that go from deep within <tt>/usr</tt> all the way to root and then
down into <tt>/etc</tt> directories.
-->
<em/重要:/ <tt>/usr</tt> パーティションは直接 root に
マウントすべきで、上記のような間接リンクにすべきではありません。
なぜなら、ずうっと根元に戻るようなリンクが、
<tt>/usr</tt> の、特に X11 で頻繁に用いられており、
これらは <tt>/usr</tt> 以下から root に戻って、
<tt>/etc</tt> ディレクトリに戻ったりするからです。

<!--O
<sect>Implementation
-->
<sect>パーティション分割の実作業
<p>
<nidx>disk!implementation</nidx>
<!--O
Having done the layout you should now have a detailled description on
what goes where. Most likely this will be on paper but hopefully
someone will make a more automated system that can deal with
everything from the design, through partitioning to formatting and
installation. This is the route one will have to take to realise the
design.
-->
設計が終わった方のために、
ここでは実際にパーティション分割を行うための詳細な手順について示します。
ここにあるのはガイダンスだけですが、
実際に行う作業を自動的に行ってくれるツールを
誰かが作ってくれると素晴らしいですね。
具体的には、設計、パーティション分割、フォーマット、
インストールということになるでしょう。

<!--O
Modern distributions come with installation tools that will guide you
through partitioning and formatting and also set up <tt>/etc/fstab</tt>
for you automatically. For later modifications, however, you will need
to understand the underlying mechanisms.
-->
最近の配布パッケージのインストーラには、
パーティション分割からフォーマット、
<tt>/etc/fstab</tt> の設定にいたるまでを
自動的に行ってくれる機能がついている場合が多いようです。
しかし後に変更したくなったときのためには、
背後で行われている実際の作業の仕組みについて知っておく必要があるでしょう。


<!--O
<sect1>Checklist
-->
<sect1>チェックリスト
<p>
<nidx>disk!implementation!checklist</nidx>
<!--O
Before starting make sure you have the following:
<itemize>
<item>Written notes of what goes where, your design
<item>A functioning, tested rescue disk
<item>A fresh backup of your precious data
<item>At least two formatted, tested and empty floppies
<item>Read and understood the man page for fdisk or equivalent
<item>Patience, concentration and elbow grease
</itemize>
-->
はじめるに当たって必要なのは…
<itemize>
<item>どれをどこに置くかのメモ (自分なりの設計)
<item>ちゃんと動作する、テスト済みのレスキューディスク。
<item>大事なデータの最新版バックアップ。
<item>フォーマットとテストをすませた空のフロッピーを最低 2 枚。
<item>fdisk（ないし同様のコマンド）の man ページを読んで理解しておくこと。
<item>根気と集中力と馬力。
</itemize>


<!--O
<sect1>Drives and Partitions
-->
<sect1>ドライブとパーティション
<p>
<nidx>disk!implementation!drives</nidx>
<nidx>disk!implementation!partitions</nidx>
<!--O
When you start DOS or the like you will find all partitions labeled
<tt/C:/ and onwards, with no differentiation on IDE, SCSI, network or
whatever type of media you have. In the world of Linux this is rather
different. During booting you will see partitions described like this:
-->
DOS などでは、起動するとすべてのパーティションが表示され、
それぞれに <tt/C:/ 以降のドライブレターが割り当てられます。
これは IDE、 SCSI、ネットワークドライブその他、
どんなメディアでも同じように扱われます。
ところが Linux の世界では少々異なります。
ブート時には以下のようなパーティションの表示が出るはずです。

<code>
Dec  6 23:45:18 demos kernel: Partition check:
Dec  6 23:45:18 demos kernel:  sda: sda1
Dec  6 23:45:18 demos kernel:  hda: hda1 hda2
</code>

<!--O
SCSI drives are labelled <tt/sda/, <tt/sdb/, <tt/sdc/ etc, and
(E)IDE drives are labelled <tt/hda/, <tt/hdb/, <tt/hdc/ etc. 
There are also standard names for all devices, full information can be
found in 
<tt>/dev/MAKEDEV</tt> and <tt>/usr/src/linux/Documentation/devices.txt</tt>.
-->
SCSI のドライブには <tt/sda/, <tt/sdb/, <tt/sdc/ のような、
また (E)IDE のドライブには <tt/hda/, <tt/hdb/, <tt/hdc/ のような名前が付きます。
すべてのデバイスには、同様に標準的な名前があります。
詳細が知りたければ 
<tt>/dev/MAKEDEV</tt> と <tt>/usr/src/linux/Documentation/devices.tex</tt> 
を見てください。

<!--O
Partitions are labelled numerically for each drive <tt/hda1/, <tt/hda2/
and so on.  On SCSI drives there can be 15 partitions per
drive, on EIDE drives there can be 63 partitions per drive. Both
limits exceed what is currently useful for most disks.
-->
パーティションはそれぞれのドライブ名に数字が付加されたものです。
つまり <tt/hda1/, <tt/hda2/ のようになります。
SCSI ドライブではドライブ一台あたり 15 パーティションまで、
EIDE ドライブでは 63 パーティションまでです。
両者とも現在のところは、ほとんどのディスクに対して充分でしょう。

<!--O
These are then mounted according to the file <tt>/etc/fstab</tt> before
they appear as a part of the file system.
-->
これらは <tt>/etc/fstab</tt> というファイルに書いてある情報に従って
マウントされ、ファイルシステムの一部となります。


<!--O
<sect1>Partitioning
-->
<sect1>パーティション分割
<p>
<nidx>disk!implementation!partitioning</nidx>
<nidx>disk!fdisk</nidx>
<nidx>disk!cfdisk</nidx>
<nidx>disk!sfdisk</nidx>
<nidx>disk!Disk Druid</nidx>

<it>It feels so good / It's a marginal risk / when I clear off / windows with fdisk! </it>
<!--O
(the Dustbunny in an 
<url url="http://www.userfriendly.org/cartoons/archives/99feb/19990221.html"
    name="issue">
of
<url url="http://www.userfriendly.org/"
    name="User Friendly">
in the song "Refund this")
-->
(Dustbunny の
<url url="http://www.userfriendly.org/"
    name="User Friendly">
中の
<url url="http://www.userfriendly.org/cartoons/archives/99feb/19990221.html"
    name="記事">
における歌 "Refund this" より。)

<!--O
First you have to partition each drive into a number of separate partitions.
Under Linux there are two main methods, <tt/fdisk/ and the more screen
oriented <tt/cfdisk/. These are complex programs, read the manual <em/very/
carefully. For the experts there is now also <tt/sfdisk/.
-->
まず最初にそれぞれのドライブをパーティションに分割する必要があります。
Linux では主として二つの選択肢があります。
<tt/fdisk/ と、これをもう少しスクリーン指向にした <tt/cfdisk/ です。
これらは複雑なプログラムですので、
マニュアルをしっかり読んでおくようにしてください。
熟練者なら、今では <tt/sfdisk/ を用いることもできます。

<!--O
Partitions come in 3 flavours, <tt/primary/, <tt/extended/ and <tt/logical/.
You have to use <tt/primary/ partitions for booting, but there is a maximum
of 4 primary partitions. If you want more you have to define an <tt/extended/
partition within which you define your <tt/logical/ partitions.
-->
パーティションには三つの種類があります。基本 (primary) パーティション、
拡張 (extended) パーティション、そして論理 (logical) パーティションです。
Linux 以外の OS をブートさせるパーティションは
基本パーティションでなければなりませんが、
これはドライブあたり 4 つまでしか用いることができません。
これ以上のパーティションを用いたい場合は拡張パーティションを指定し、
その中に複数の論理パーティションを作成します。

<!--O
Each partition has an identifier number which tells the operating system
what it is, for Linux the types <tt/swap(82)/ and <tt/ext2fs(83)/ are
the ones you
will need to know.
If you want to use RAID with autostart you have to check the documentation
for the appropriate type number for the RAID partition.
-->
各々のパーティションには、対応する OS に応じた id 番号がふられています。
Linux の場合は <tt/swap(82)/ と <tt/ext2fs(83)/ を使います。
RAID を autostart で使いたい場合に、
RAID パーティションに用いるべきタイプ番号については、
ドキュメントをチェックしておく必要があります。

<!--O
There is a readme file that comes with <tt/fdisk/ that gives more in-depth
information on partitioning.
-->
<tt/fdisk/ に付属の readme ファイルには、
パーティション分割に関するより詳細な情報が記載されています。

<!--O
Someone has just made a <em/Partitioning HOWTO/ which contains excellent,
in depth information on the nitty-gritty of partitioning. Rather than
repeating it here and bloating this document further, I will instead refer
you to it instead.
-->
最近 <em/Partitioning HOWTO/ という文書が出たようです。
これにはパーティション分割のあれこれに関する詳細な情報が
非常に良くまとめられています。
その内容をここに繰り返してこの文書をさらに巨大化させるのは止めておきます。
<em/Partitioning HOWTO/ を読んでいただくことをおすすめします。

訳注:
<url url="http://www.linux.or.jp/JF/JFdocs/Partition.html"
  name="Partition HOWTO の日本語訳">
は JF にあります。

<!--O
Redhat has written a screen oriented utility called <em/Disk Druid/ which
is supposed to be a user friendly alternative
to <tt/fdisk/ and <tt/cfdisk/ and also
automates a few other things. Unfortunately this product is not quite
mature so if you use it and cannot get it to work you are well advised
to try <tt/fdisk/ or <tt/cfdisk/.
-->
Redhat は <em/Disk Druid/ というスクリーン指向のユーティリティを作成しました。
これは <tt/fdisk/ や <tt/cfdisk/ と同じ動作をする
ユーザーフレンドリなプログラムで、いくつかの作業を自動化もしてくれます。
残念ながらこの製品はまだあまり枯れていないので、
うまく動かないことがあるかもしれません。
その場合は <tt/fdisk/ か <tt/cfdisk/ を使ってください。

<!--O
Not to be outdone, Mandrakesoft has made an even more graphic alternative
called
<url url="http://www.linux-mandrake.com/diskdrake/"
    name="Diskdrake">
that also offers numerous features.
-->
さらに Mandrakesoft も負けじと、よりグラフィカルなツール
<url url="http://www.linux-mandrake.com/diskdrake/"
    name="Diskdrake">
を開発しました。こちらも、とてもたくさんの機能を持っています。

<!--O
Also the GNU project offers a partitioning tool called
<url url="http://www.gnu.org/software/parted/"
    name="GNU Parted">
-->
GNU project も
<url url="http://www.gnu.org/software/parted/"
    name="GNU Parted">
というパーティション分割ツールを提供しています。

<!--O
The 
<url url="http://www.users.intercom.com/&tilde;ranish/part/"
    name="Ranish Partition Manager">
is another free alternative,
while
<url url="http://www.powerquest.com"
    name="Partition Magic">
is a popular commercial alternative which also offers some
support for resizing <tt/ext2fs/ partitions.
-->
<url url="http://www.users.intercom.com/&tilde;ranish/part/"
    name="Ranish Partition Manager">
というフリーのソフトウェアや、商用で良く使われているものでは
<url url="http://www.powerquest.com"
    name="Partition Magic">
などもあります。後者では <tt/ext2fs/
パーティションのサイズ変更もある程度サポートしています。

<!--O
Note that Windows will complain if it finds
more than one primary partition on a drive.
Also it appears to assign drive letters
to primary partitions as it finds disks
before starting over from the first disk to
assign subsequent drive names to logical partitions.
-->
Windows は一つのドライブに二つ以上の基本パーティションがあると
文句を行ってきます。また Windows でのドライブレターの割り当てでは、
まず基本パーティションをすべてのドライブから探し、
その後で論理パーティションをそれぞれのディスクで再走査するようです。

<!--O
If you want DOS/Windows on your system you should make that partition
first, a primary one to boot to, made with the DOS <tt/fdisk/ program.
Then if you want NT you put that one in.
Finally, for Linux, you create those partitions with the Linux <tt/fdisk/
program or equivalents. Linux is flexible enough to boot from both
primary as well as logical partitions.
-->
DOS/Windows をシステムに共存させたい場合には、
まず最初に DOS の <tt/fdisk/ プログラムを使ってそれらをブートさせる
基本パーティションを作成する必要があります。
さらに NT が必要なら、この段階で配置します。
最後に Linux のためのパーティションを
Linux の <tt/fdisk/ プログラム群を用いて作成します。
Linux は柔軟ですので、
基本パーティションからでも論理パーティションからでもブートできます。

<!--O
In depth information on DOS <tt/fdisk/ can be found at
<url url="http://www.fdisk.com/fdisk/"
    name="Fdisk.com">
and
<url url="http://members.aol.com/axcel216/secrets.htm"
    name="MS-DOS 5.00 - 7.10 Undocumented, Secret + Hidden Features">
which details even more bugs and pitfalls.
-->
DOS の <tt/fdisk/ に関する非常に詳しい情報が
<url url="http://www.fdisk.com/fdisk/"
    name="Fdisk.com">
と
<url url="http://members.aol.com/axcel216/secrets.htm"
    name="MS-DOS 5.00 - 7.10 Undocumented, Secret + Hidden Features">
から入手できます。バグや落とし穴に関しても詳しいです。

<!--O
<sect1>Repartitioning <label id="repartitioning">
-->
<sect1>再パーティション <label id="repartitioning">
<p>
<nidx>disk!implementation!repartitioning</nidx>
<nidx>disk!ShowFat</nidx>
<nidx>disk!fips</nidx>
<nidx>disk!Partition Magic</nidx>
<nidx>disk!Partition Resizer</nidx>
<!--O
Sometimes it is necessary to change the sizes of existing partitions
while keeping the contents intact. One way is of course to back up
everything, recreate new partitions and then restore the old contents,
and while this gives your back up system a good test it is also
rather time consuming.
-->
時には既存のパーティションのサイズを、
内部のデータを保ったままで変更しなければならないかもしれません。
もちろん一つの方法としては、
すべてをバックアップしてパーティションを作り直し、
元の中身をレストアすれば良いのです。
これはバックアップシステムの良いテストにもなりますが、
しかし時間もかかります。

<!--O
Partition resizing is a simpler alternative where a file system is
first shrunk to desired volume and then the partition table is
updated to reflect the new end of partition position. This process
is therefore very file system sensitive.
-->
もう少し楽な別法として、
パーティションをリサイズ (resizing) する方法もあります。
ここではまずどれかのファイルシステムを望む容量に縮めて、
それからそのパーティションの末尾にあわせて
パーティションテーブルを書き換えます。
したがってこの手法はファイルシステムに依存します。

<!--O
Repartitioning requires there to be free space at the end of
the file space so to ensure you are able to shrink the size
you should first defragment your drive and empty any wastebaskets.
-->
パーティションをしなおすには、サイズを縮めるために
ファイルシステムの末尾に空きスペースが必要です。
まずデフラグメントを行って、
ドライブに空白の隙間がないようにしてください。

<!--O
Using 
<url url="http://www.igd.fhg.de/&tilde;aschaefe/fips/"
    name="fips">
you can resize a <tt/fat/ partition,
and the latest version 1.6 of <tt/fips/ or <tt/fips 2.0/
are also able to resize <tt/fat32/ partition.
Note that these programs actually run under DOS.
-->
<url url="http://www.igd.fhg.de/&tilde;aschaefe/fips/"
    name="fips">
を用いれば <tt/fat/ パーティションをリサイズできます。
<tt/fips/ の最新版である 1.6 版や <tt/fips 2.0/ を使えば、
<tt/fat32/ のパーティションもリサイズできます。
これらのプログラムは DOS の下で動作します。

<!--O
Resizing other file systems are much more complicated but one
popular commercial system
<url url="http://www.powerquest.com"
    name="Partition Magic">
is able to resize more file system types, including <tt/ext2fs/
using the <tt/resize2fs/ program. Make sure you get the latest
updates to this program as recent versions had problems with
large disks.
-->
その他のファイルシステムのリサイズはずっと難しいのですが、
有名な商用ソフトウェアの
<url url="http://www.powerquest.com"
    name="Partition Magic">
では、 <tt/resize2fs/ を用いて
<tt/ext2fs/ を含むより多くのファイルシステムをリサイズできます。
最近、大きなディスクに対して問題が生じる版があったので、
最新版を入手するようにしてください。

<!--O
In order to get the most out of <tt/fips/ you should
first delete unnecessary files, empty wastebaskets etc.
before defragmenting your drive.
This way you can allocate more space to other partitions.
If the program complains there are still files at the end
of your drive it is probably hidden files generated by
Microsoft Mirror or Norton Image.
These are probably called <tt/image.idx/ and <tt/image.dat/ and
contain backups of some system files.
-->
<tt/fips/ の効果を最大にするには、ドライブのデフラグメントを行う前に
まず不必要なファイルや空き領域を削除する必要があります。
こうすれば他のパーティションにより多くの空間を割り当てられます。
プログラムが「ドライブの末尾にファイルがある」と文句を言ってきた場合、
それは Microsoft Mirror か Norton Image によって作成された
隠し属性のファイルである可能性が高いです。
それらには <tt/image.idx/ や <tt/image.dat/ という名前がついており、
いくつかのシステムファイルのバックアップ情報を保持しています。

<!--O
There are reports that in some Windows defragmentation programs
you should make sure the box "allow Windows to move files around"
is <em/not/ checked, otherwise you will end up with some files
in the last cylinder of the partition which will prevent FIPS
from reclaiming space.
-->
いくつかの報告によれば、 Windows のデフラグメントツールによっては、
"Windows にファイルの再配置を許可する (allow Windows to move files around)"
というボックスを<em/チェックしない/ようにする必要があるのだそうです。
そうしないといくつかのファイルが末尾のシリンダに配置されてしまうので、
FIPS はその空間を埋め立てることができなくなってしまいます。

<!--O
If you still have unmovable files at the end of your DOS partition
you should get the DOS program
<url url="http://www8.pair.com/dmurdoch/programs/showfat.htm"
    name="showfat">
version 3.0 or higher.
This shows you what files are where so you can deal with them
directly.
-->
どうしても DOS パーティションの末尾に動かせないファイルが残ってしまう場合は、
DOS プログラム
<url url="http://www8.pair.com/dmurdoch/programs/showfat.htm"
    name="showfat">
の 3.0 版以降を入手しましょう。
このプログラムはそこにあるファイルを表示してくれますので、
直接扱うことが可能になります。

<!--O
A freeware alternative is
<!-\- <url url="http://members.xoom.com/Zeleps" 001203 -\->
<url url="http://members.nbci.com/Zeleps/"
    name="Partition Resizer">
which can shrink, grow and move partitions.
-->
同じ機能を持ったフリーウェア版としては
<url url="http://members.nbci.com/Zeleps/"
    name="Partition Resizer">
があります。パーティションの縮小・拡大・移動ができます。

<!--O
Some versions of DOS / Windows have a hidden flag for <tt/defrag/, "<tt>/P</tt> that
causes <tt/defrag/ to move even hidden files. Use at own risk.
-->
DOS / Windows の版によっては、 <tt/defrag/ に隠しオプション
<tt>/P</tt> があり、これを指定すると <tt/defrag/ は
hidden ファイルも移動するようになります。 at your own risk でどうぞ。

<!--O
Repartitioning is as dangerous process as any other partitioning
so you are advised to have a fresh backup handy.
-->
パーティションの切り直しはとても危険な作業ですから、
最新のバックアップを手元に置いておくようにしましょう。

<!--O
<sect1>Microsoft Partition Bug <label id="microsoft-partition-bug">
-->
<sect1>Microsoft パーティションのバグ<label id="microsoft-partition-bug">
<p>
<nidx>disk!implementation!Microsoft Partition Bug</nidx>
<nidx>disk!Microsoft!nasty bug</nidx>
<!--O
In Microsoft products all the way up to Win 98 there is a tricky bug
that can cause you a bit of trouble:
if you have several primary <tt/fat/ partitions
and the last extended partition is not a <tt/fat/ partition
the Microsoft system will try to mount the last partition as if
it were a FAT partition in place of the last primary FAT partition.
-->
Windows 98 に至るまでのすべての Microsoft 製品にはちょっと面倒なバグがあって、
これが少々問題になる人もいるかもしれません。
<tt/fat/ パーティションを複数使っているとき、
拡張パーティションの末尾が <tt/fat/ パーティションでないと、
Microsoft のシステムは
「基本パーティションの末尾にある FAT パーティション」の代わりに
「末尾の拡張パーティション」を FAT パーティションとして
マウントしようとしてしまうのです。

<!--O
There is more
<!-\- <url url="http://www.v-com.com/support/osinstalls/notes/95notes.html" -\->
<url url="http://www.v-com.com/"
    name="information">
available on the net on this.
-->
この問題に関する
<url url="http://www.v-com.com/"
    name="詳細な情報">
は、ネットワークから入手できます。

<!--O
To avoid this you can place a small logical <tt/fat/ partition
at the very end of your disk.
-->
これを避けるには、小さな論理 <tt/fat/ パーティションを
ディスクの一番最後に配置すれば OK です。

<!--O
More information on multi OS installations are available at
<url url="http://www.v-com.com/"
    name="V Communications"> but they keep rearranging the
links continuously so no direct links can be offered here.
-->
マルチ OS のインストールに関する詳しい情報は
<url url="http://www.v-com.com/"
    name="V Communications">
からも入手できます。
しかし彼らはリンクをいじり続けているので、
ここでは直接のリンクを掲載できません。

<!--O
Since some hardware comes with setup software that is available
under DOS only this could come in handy anyway. Notable examples
are RAID controllers from DPT and a number of networking cards.
-->
ハードウェアの設定ソフトには DOS でしか動かないものもありますから、
このパーティションは多少は役にたつでしょう。たとえば
DPT の RAID コントローラや多くのネットワークカードなどがそうですね。


<!--O
<sect1>Multiple Devices (<tt>md</tt>)
-->
<sect1>複数デバイスの一括利用  (md: Multiple Devices)
<p>
<nidx>disk!implementation!multiple devices</nidx>
<nidx>disk!implementation!devices, multiple</nidx>
<!--O
Being in a state of flux you should make sure to read the latest
documentation on this kernel feature. It is not yet stable, beware.
-->
これはカーネルに付属の機能です。まだ開発は続いていますので、
最新のドキュメントを良く読んでおくようにしてください。
不安定かも知れませんので、注意してください。

<!--O
Briefly explained it works by adding partitions together into new
devices <tt/md0/, <tt/md1/ etc. using <tt/mdadd/ before you activate
them using <tt/mdrun/. This process can be automated using the file
<tt>/etc/mdtab</tt>.
-->
簡単に説明しますと、この機能は複数のデバイスをまとめて、
<tt/md0/ (あるいは <tt/md1/) という新しいデバイスを作ります。
この際には <tt/mdadd/ というプログラムが用いられ、
<tt/mdrun/ によって利用できるようになります。この作業は
<tt>/etc/mdtab</tt> というファイルによって自動化が可能です。

<!--O
The latest <tt/md/ system uses a  <!-\- <file>/etc/raidtab</file> -\->
<htmlurl url="file:///etc/raidtab"
    name="/etc/raidtab">
and
a different syntax. Make sure your RAID-tools package matches
the <tt/md/ version as the internal protocol has changed.
-->
最新版の <tt/md/ システムでは
<htmlurl url="file:///etc/raidtab"
    name="/etc/raidtab">
を用い、
これは別の書式で書きます。使っている RAID-tools のパッケージが
<tt/md/ のバージョンとマッチしているか確認してください。
内部で用いているプロトコルが変更されていますので。

<!--O
Then you then treat these like any other partition on a drive. Proceed
with formatting etc. as described below using these new devices.
-->
<tt/mdrun/ 以降には、
このデバイスは他のドライブパーティションと全く同じように使うことができます。
以下の記述に従って、フォーマット等の作業を行なってください。

<!--O
There is now also a HOWTO in development for RAID using <tt/md/ you
should read.
-->
<tt/md/ を用いた RAID に関する HOWTO も発展途上にあります。
読んでおきましょう。


<!--O
<sect1>Formatting
-->
<sect1>フォーマット
<p>
<nidx>disk!implementation!formatting</nidx>
<!--O
Next comes partition formatting, putting down the data structures that will
describe the files and where they are located. If this is the first time it
is recommended you use formatting with verify. Strictly speaking it should
not be necessary but this exercises the I/O hard enough that it can uncover
potential problems, such as incorrect termination, before you store your
precious data. Look up the command <tt/mkfs/ for more details.
-->
次に行なうのはパーティションのフォーマットです。
この作業は、ディスク表面にデータ構造を書き込み、
ファイルの書き込み位置を指定できるようにするためのものです。
一番最初にフォーマットを行なう場合は、
同時にベリファイを行なうように指定すると良いでしょう。
この作業は本来の目的には必要ないのですが、
ディスク I/Oのテストとして有効です。
ディスク入出力が連続して頻繁に行われるので、
潜在的な問題 (ターミネーションの不正など) を発見できる可能性があります。
ベリファイ機能の詳細に関しては <tt/mkfs/ のマニュアルを見てください。

<!--O
Linux can support a great number of file systems, rather than repeating
the details you can read the man page for <tt/fs/ which describes them in
some details. Note that your kernel has to have the drivers compiled in
or made as modules in order to be able to use these features. When the time
comes for kernel compiling you should read carefully through the file system
feature list. If you use <tt/make menuconfig/ you can get online help for
each file system type.
-->
Linux は非常に多くのファイルシステムをサポートしています。
ここでそのすべてを挙げることもできますが、
<tt/man fs/ してもらう方が良いでしょう。
ここには各々のファイルシステムに関する情報も多少書かれています。
なおこれらのファイルシステムを用いるには、
それに応じたドライバをカーネルに組み込む
(あるいはモジュールとして用意する) 必要があります。
カーネルをコンパイルする際に、
ファイルシステム機能のリストを注意して読むようにしてください。
<tt/make menuconfig/ を用いれば、
それぞれのファイルシステムに関するオンラインヘルプを見ることもできます。

<!--O
Note that some rescue disk systems require <tt/minix/, <tt/msdos/ and <tt/ext2fs/
to be compiled into the kernel.
-->
レスキューディスク作成パッケージには、
<tt/minix/, <tt/msdos/, <tt/ext2fs/
のサポートをカーネルに組み込んでいないと使えないものがあるようです。

<!--O
Also swap partitions have to be prepared, and for this you use <tt/mkswap/.
-->
スワップデバイスにおいても、
フォーマットに準ずる作業を行なう必要があります。
これには <tt/mkswap/ を用います。

<!--O
Some important notes on formatting with DOS and Windows can be found in
<url url="http://members.aol.com/axcel216/secrets.htm"
    name="MS-DOS 5.00 - 7.10 Undocumented, Secret + Hidden Features">.
-->
DOS や Windows でのフォーマットに関する重要な内容が
<url url="http://members.aol.com/axcel216/secrets.htm"
    name="MS-DOS 5.00 - 7.10 Undocumented, Secret + Hidden Features">
にあります。

<!--O
Note that this formatting is high level formatting, that writes the file
system to the disk, as opposed to low level formatting that lays down
tracks and sectors. The latter is hardly ever needed these days.
-->
ここでの「フォーマット」は高レベルのフォーマットのことであり、
ファイルシステムをディスクに作成するものです。これに対して
低レベルのフォーマットは、トラックとセクタをディスクに配置します。
後者は今日ではほとんど必要ありません。


<!--O
<sect1>Mounting
-->
<sect1>マウント
<p>
<nidx>disk!implementation!mounting</nidx>
<!--O
Data on a partition is not available to the file system until it is mounted
on a mount point. This can be done manually using <tt/mount/ or automatically
during booting by adding appropriate lines to <tt>/etc/fstab</tt>. Read the
manual for <tt/mount/ and pay close attention to the tabulation.
-->
パーティション上にデータを読み書きするには、
まず適切なマウントポイントにそのパーティションをマウントしなければなりません。
これを手動で行なうには <tt/mount/ コマンドを用います。
またブート時に自動的に行なうには、必要な情報を
<tt>/etc/fstab</tt> ファイルに追加します。
後者を行なう際には <tt/mount/ の man ページをよく読んでください。
記述を間違えた場合は、最悪システムが立ち上がらなくなる場合があります。


<sect1><tt/fstab/
<p>
<nidx>disk!implementation!fstab</nidx>
<nidx>disk!fstab</nidx>
<!--O
During the booting process the system mounts all partitions
as described in the <tt/fstab/ file which can look something
like this:
-->
ブート動作の途中で、システムは <tt/fstab/ ファイルの記述に従って
すべてのパーティションをマウントします。
以下のような内容になっているでしょう。

<code>
# <file system>   <mount point>   <type>  <options>   <dump>  <pass>
/dev/hda2          /               ext2    defaults    0       1
None               none            swap    sw          0       0
proc               /proc           proc    defaults    0       0
/dev/hda1          /dosc           vfat    defaults    0       1
</code>

<!--O
This file is somewhat sensitive to the formatting used so it
is best and also most convenient to edit it using one of the
editing tools made for this purpose,
such as
<url url="http://www.bit.net.au/&tilde;bhepple/fstool/"
    name="on the netfstool">, a Tcl/Tk-based file system mounter,
and
<url url="http://kfstab.purespace.de/kfstab/"
    name="kfstab">, an editing tool for KDE.
-->
このファイルは書式に厳しいので、
専用のエディットツールを用いるほうが良いし、また便利でしょう。
例えば Tcl/Tk ベースのファイルシステムマウンターである
<url url="http://www.bit.net.au/&tilde;bhepple/fstool/"
    name="on the netfstool"> や、KDE のエディットツール
<url url="http://kfstab.purespace.de/kfstab/"
    name="kfstab">などがあります。

<!--O
Briefly, the fields are partition name, where to mount the partition,
type of file system, mount options, when to dump for backup
and when to do <tt/fsck/.
-->
それぞれのフィールドを順に簡単に紹介すると、
パーティションの名前、マウント先、
ファイルシステムのタイプ、マウントのオプション、
いつ dump してバックアップをとるか、
そしていつ <tt/fsck/ するか、です。

<!--O
Linux offers the possibility of parallel file checking (<tt/fsck/)
but to be efficient it is important not to <tt/fsck/ more than one
partition on a drive at a time.
-->
Linux ではファイルチェック (<tt/fsck/) を並列動作させることも可能です。
しかし効率のためには、一つのドライブ上にある複数のファイルシステムは
同時に <tt/fsck/ させないことが大事です。


<!--O
<sect1>Mount options
-->
<sect1>マウントオプション
<p>
<nidx>disk!mount</nidx>
<!--O
Mounting, either by hand or using the <tt>fstab</tt>, allows for
a number of options that offers extra protection. Below are some
of the more useful options.
-->
(手動にしろ <tt/fstab/ 経由にしろ) マウントの際には
たくさんのオプションが利用でき、様々な保護が可能になっています。
以下では中でも便利なオプションを紹介します。

<descrip>
<!--O
<tag/nodev/ Do  not interpret character or block special
devices on the file system.
-->
<tag/nodev/ このファイルシステム上のキャラクタスペシャルデバイスや
ブロックスペシャルデバイスを利用禁止にする。

<!--O
<tag/noexec/ This disallows execution of any binaries on
the mounted file system. Useful in spool areas.
-->
<tag/noexec/
マウントされたファイルシステム上のバイナリを実行禁止にする。
スプール領域に便利。

<!--O
<tag/nosuid/ This disallows set-user-identifier or
set-group-identifier on the mounted file system.
Useful in home directories.
-->
<tag/nosuid/
マウントされたファイルシステム上での SUID, SGID を禁止する。
ホームディレクトリに便利。
</descrip>

<!--O
For more information and cautions refer to the man page
for <tt/mount/ and <tt/fstab/.
-->
より詳しい情報や注意点については
<tt/mount/ や <tt/fstab/ のマニュアルページを見てください。

<!--O
<sect1>Recommendations
-->
<sect1>お勧め
<p>
<!--O
Having constructed and implemented your clever scheme
you are well advised to make a complete record of it all, on paper.
After all having all the necessary information on disk is no use
if the machine is down.
-->
設定と実装を賢く行うことができたら、
すべてを「紙に」記録しておきましょう。
ディスク上の情報は、マシンがダウンしたら全く使えませんからね。

<!--O
Partition tables can be damaged or lost, in which case it is
excruciatingly important that you enter the exact same numbers
into <tt/fdisk/ so you can rescue your system.
You can use the program <tt/printpar/ to make a clear record
of the tables. Also write down the SCSI numbers or IDE names
for each disk so you can put the system together again in the
right order.
-->
パーティションテーブルは破壊されたり失われたりすることもあります。
その場合には、 <tt/fdisk/ の正確な数値の記録が
ものすごく価値を持つことになります。
その値を入力すればシステムを救うことができるのですから。
<tt/printpar/ プログラムを用いて、
テーブルをわかりやすい形に記録しておくこともできます。
またそれぞれのディスクの SCSI 番号や IDE 名も書いておきましょう。
そうしないとシステムを正しい順序で再構成できません。

<!--O
There is also a small script in appendix
<ref id="disk-documenter" name="Appendix M: Disk System Documenter">
which will generate a summary of your disk configurations.
-->
<ref id="disk-documenter" name="付録 M:">
にも、
現在のディスクの設定のサマリを生成する
小さなスクリプトを置いておきました。

<!--O
For checking your hard disks you can use the Disk Advisor boot disk
available
<url url="http://www.ontrack.com/"
    name="on the net">.
The disk builder required Windows to run. This system is useful to
diagnose failed disks.
-->
ハードディスクのチェックには、
ネットから入手できる
<url url="http://www.ontrack.com/"
    name="Disk Advisor boot disk">
が利用できます。 disk builder を実行するには Windows が必要でした。
このシステムはおかしくなったディスクの診断に有用です。

<!--O
You are strongly recommended to make a rescue disk and <em>test</em> it.
Most distributions make on available and is often part of the
installation disks. For some, such as the one for Redhat 6.1 the way
to invoke the disk as a rescue disk is to type <em>linux rescue</em>
at the boot prompt.
-->
なお、レスキューディスクは是非作成して<em>テスト</em>しておきましょう。
ほとんどのディストリビューションで
(おそらくインストールディスクの一部として) 提供されています。
RedHat 6.1 などの一部のディストリビューションでは、
ディスクをレスキュー用途で起動するには、
ブートプロンプトで <em>linux rescue</em> とタイプすることになっています。

<!--O
There are also specialised rescue disk distributions available
on the net.
-->
レスキュー用途に特化したディスクもネットで配布されています。

<!--O
When need for it comes you will need to know where your root and boot
partitions reside which you need to write down and keep safe.
-->
これらが必要になったときは、システムの root と boot パーティションが
どこにあり、どこに書いてよいか・いけないかを把握している必要があります。

<!--O
Note: the difference between a boot disk and a rescue disk is that
a boot disk will fail if it cannot mount the file system, typically
on your hard disk. A rescue disk is self contained and will work
even if there are no hard disks.
-->
メモ: ブートディスクとレスキューディスクの違いは、
前者はファイルシステムを (通常はハードディスク上のものを)
マウントできない場合、起動に失敗するという点にあります。
レスキューディスクはそれ自体でシステムをなしており、
ハードディスクがなくても動作します。


<!--O
<sect>Maintenance
-->
<sect>メンテナンス
<p>
<nidx>disk!maintenance</nidx>
<!--O
It is the duty of the system manager to keep an eye on the drives
and partitions. Should any of the partitions overflow, the system
is likely to stop working properly, no matter how much space is
available on other partitions, until space is reclaimed.
-->
ドライブとパーティションを監視し続けることは
システム管理者の義務であると言えます。
どこかのパーティションが一杯になってしまえば、
パーティション容量の再配置がすむまで
システムは正しく働かなくなってしまうのですから。

<!--O
Partitions and disks are easily monitored using <tt>df</tt> and
should be done
frequently, perhaps using a cron job or some other general system
management tool.
-->
パーティションとディスクの監視は df コマンドによって簡単に行えます。
頻繁に行うべきですし、
cron や他の管理ツールなどを使って定期的に行うようにするのも良いでしょう。

<!--O
Do not forget the swap partitions, these are best monitored using
one of the memory statistics programs such as
<tt>free</tt>, <tt>procinfo</tt> or <tt>top</tt>.
-->
スワップパーティションも忘れないようにしましょう。
<tt/free/ や <tt/procinfo/, <tt/top/
といったメモリ利用の統計表示ツールを用いることで監視できます。

<!--O
Drive usage monitoring is more difficult but it is important for
the sake of performance to avoid contention - placing too much
demand on a single drive if others are available and idle.
-->
ドライブの使用状況のモニタはもうちょっと難しいですが、
ドライブ利用の競合を避けてシステムの性能を上げるには重要な作業です。
アクセス要求がひとつのディスクに偏らないようにしましょう。

<!--O
It is important when installing software packages to have a clear
idea where the various files go. As previously mentioned GCC keeps
binaries in a library directory and there are also other programs
that for historical reasons are hard to figure out, X11 for instance
has an unusually complex structure.
-->
ソフトウェアのパッケージをインストールするとき、
どこにどのファイルを配置するかについて
明確な意図を持つようにすることも重要です。
先に紹介したように、
GCC は実行バイナリをライブラリのディレクトリに置きます。
他にも歴史的な経緯から、わけのわからない配置をするパッケージもあります。
X11 なんかがそうですね。

<!--O
When your system is about to fill up it is about time to check and
prune old logging messages as well as hunt down core files. Proper
use of <tt/ulimit/ in global shell settings can help saving you
from having core files littered around the system.
-->
お使いのシステムのディスクが一杯になりかけたら、
まず古いログを探して消去しましょう。
core ファイルも探してみましょう。シェルのグローバルな設定に
<tt/ulimit/ を正しく用いておくと、
core でシステムをいっぱいにせずにすみます。
<!--CC should be moved to "Deletions" sec? -->

<!--O
<sect1>Backup
-->
<sect1>バックアップ
<p>
<nidx>disk!maintenance!backup</nidx>
<!--O
The observant reader might have noticed a few hints about the usefulness
of making backups. Horror stories are legio about accidents and what
happened to the person responsible when the backup turned out to be
non-functional or even non existent. You might find it simpler to invest
in proper backups than a second, secret identity.
-->
これまでの部分をじっくりと読んできた方は、
すでに何回かバックアップの重要性に触れてきたことに気付いたでしょう。
クラッシュに当たってバックアップが機能していなかった、
あるいは存在すらしなかった場合に管理者に降りかかる災厄については
恐ろしい話がたくさんあります。クラッシュが起こってからじたばたするよりは、
普段からバックアップに投資しておく方がはるかに話は簡単になるはずです。

<!--O
There are many options and also a mini-HOWTO ( <tt/Backup-With-MSDOS/ )
detailling what you need to know. In addition to the DOS specifics it
also contains general information and further leads.
-->
バックアップには色々な手段が可能ですが、この辺りの詳細は 
<em/Backup-with-MSDOS-mini-HOWTO/ に記述があります。
この文書には DOS に関する話だけではなく、
一般的な情報や、より詳細な情報へのポインタも書いてあります。

訳注:
<url url="http://www.linux.or.jp/JF/JFdocs/Backup-With-MSDOS.html"
  name="Backup-With-MSDOS.html の日本語訳">
は JF にあります。同種の文書として
<url url="http://www.linux.or.jp/JF/JFdocs/dump-restore-mini-HOWTO.html"
  name="dump and restore mini HOWTO">
もおすすめです。

<!--O
In addition to making these backups you should also make sure you can
restore the data. Not all systems verify that the data written is
correct and many administrators have started restoring the system after
an accident happy in the belief that everything is working, only to
discover to their horror that the backups were useless. Be careful.
-->
ただバックアップをとるだけでなく、
バックアップデータをちゃんと復元できるかどうかも確認しておきましょう。
恐い話をひとつ。心掛けの良かった管理者がクラッシュに遭遇。
「ああ、普段からバックアップを取っていて本当に良かった」
バックアップデータの復元をはじめたら、何とそのデータが壊れていた...
気をつけましょうね。

<!-- 0.24 -->
<!--O
There are both free and commercial backup systems available for Linux.
One commercial example is the disk image level backup system from
<url url="http://www.estinc.com/"
    name="QuickStart">
offering a full function 30 day Linux demo available online.
-->
Linux のバックアップソフトには、フリーなものも商用のものも存在します。
商用のものの例としては、ディスクイメージレベルでのバックアップシステムを
<url url="http://www.estinc.com/"
    name="QuickStart">
が提供しています。完全機能する 30 日限定の
Linux 用デモ版がオンラインで入手できます。


<!--O
<sect1>Defragmentation
-->
<sect1>デフラグメント
<p>
<nidx>disk!maintenance!defragmentation</nidx>
<!--O
This is very dependent on the file system design, some suffer fast and
nearly debilitating fragmentation. Fortunately for us, <tt/ext2fs/ does
not belong to this group and therefore there has been very little talk
about defragmentation tools. It does in fact exist but is hardly ever
needed. 
-->
これはファイルシステムの設計によって随分違います。
早い段階からフラグメンテーションが起きてしまい、
しかもそれによって非常に速度が低下するようなシステムもあります。
幸いなことに <tt/ext2fs/ はそうではないので、
デフラグメントツールに関してもほとんど話題になることはありませんでした。
実はちゃんと存在しているのですが、これまではほとんど必要なかったのです。

<!--O
If for some reason you feel this is necessary, the quick and easy solution
is to do a backup and a restore. If only a small area is affected, for instance
the home directories, you could <tt/tar/ it over to a temporary area on
another partition, <em/verify/ the archive, delete the original
and then untar it back again.
-->
なんらかの理由でデフラグメント作業が必要になった場合は、
バックアップとレストアを行なってしまうのが簡単でしょう。
例えばホームディレクトリのような小さな領域だけならば、
その領域を <tt/tar/ で別のパーティションに一時待避し、
<em/アーカイブを確認して/、
オリジナルを消してから再書き込みすれば良いでしょう。

<!--O
<sect1>Deletions
-->
<sect1>不要ファイルの削除
<p>
<nidx>disk!maintenance!deletions</nidx>
<!--O
Quite often disk space shortages can be remedied simply by deleting unnecessary
files that accumulate around the system. Quite often programs that terminate
abnormally cause all kinds of mess lying around the oddest places. Normally a
core dump results after such an incident and unless you are going to debug it
you can simply delete it. These can be found everywhere so you are advised to do
a global search for them now and then.
The <tt>locate</tt> command is useful for this.
-->
ディスク領域の不足が、システムのあちこちに散らばっている
不必要なファイルを削除するだけで解消してしまうことも良くあるものです。
異常終了したプログラムは、さまざまなガラクタを、
思いもよらないような場所に残してしまうことが良くあります。
このような事故があった場合には、通常はコアダンプが残されます。
デバッグを行わないならば単に削除してかまいません。
コアダンプはどこにでも作成されますから、
ときどきグローバルに検索を行うと良いでしょう。
これには <tt/locate/ コマンドが便利です。

<!--O
Unexpected termination can also cause all sorts of temporary files remaining in
places like <tt>/tmp</tt> or <tt>/var/tmp</tt>, files that are automatically
removed when the program ends normally. Rebooting cleans up some of these areas
but not necessary all and if you have a long uptime you could end up with a lot
of old junk. If space is short you have to delete with care, make sure the file
is not in active use first. Utilities like <tt/file/ can often tell you what kind
of file you are looking at.
-->
正常に終了しなかったプログラムは、
いろいろな種類の一時ファイルを残すこともあります。
これらは <tt>/tmp</tt> や <tt>/var/tmp</tt> に置かれ、
通常ならプログラムの終了時に自動的に削除されるはずのものです。
このような領域は再起動を行えばきれいにされるはずですが、
すべてがそうであるとは限りませんし、
uptime が長ければ大量のゴミが溜まることになってしまいます。
領域が足りなくなったら、注意しながら削除しましょう。
そのファイルが現在使われているものではないことを、
まず確認してから削除するようにしましょう。
<tt/file/ のようなユーティリティを用いれば、
そのファイルが何であるかわかることも多いです。

<!--O
Many things are logged when the system is running, mostly to files in the
<tt>/var/log</tt> area. In particular the file <tt>/var/log/messages</tt> tends
to grow until deleted. It is a good idea to keep a small archive of old log
files around for comparison should the system start to behave oddly.
-->
システムが動作している場合には、多くの記録が残されます。
それらの多くは <tt>/var/log</tt> ディレクトリに保存されます。
特に <tt>/var/log/messages</tt> は、
削除しないとどんどん大きくなります。
古いログファイルからなる小さなアーカイブを
いくつか用意しておくと良いと思います。
それらを比較すれば、
システムがおかしくなりかかっていないかをチェックできますから。

<!--O
If the mail or news system is not working properly you could have
excessive growth in their spool areas, <tt>/var/spool/mail</tt>
and <tt>/var/spool/news</tt> respectively. Beware of the overview files
as these have a leading dot which makes them invisible to <tt/ls -l/, it
is always better to use <tt/ls -Al/ which will reveal them.
-->
メールまたはニュースのシステムが正しく動作していないと、
スプール領域が余計に消費されます。
それぞれ <tt>/var/spool/mail</tt> と <tt>/var/spool/news</tt> です。
overview ファイルには注意すること。
このファイルには先頭にドットがついているので、
<tt/ls -l/ しただけでは見えません。
<tt/ls -Al/ を用いて、これらのファイルにも常に注意するように。

<!--O
User space overflow is a particularly tricky topic. Wars have been waged between
system administrators and users. Tact, diplomacy and a generous budget for new
drives is what is needed. Make use of the message-of-the-day feature, information
displayed during login from the <tt>/etc/motd</tt> file to tell users when space
is short.
Setting the default shell settings to prevent core files being dumped can save you
a lot of work too.
-->
ユーザー領域のオーバーフローは特に難しい問題です。
システム管理者とユーザの間には、ずっと闘争が行われ続けています。
気転や交渉術が必要です。
時には実際に新たなドライブを購入してあげる必要もあるでしょう。
message-of-the-day の機能
(ログインしたときに <tt>/etc/motd</tt> の内容が表示される)
をうまく使いましょう。ディスクが足りなくなった場合は、
これでユーザーに知らせるようにしましょう。
また shell のデフォルトの設定で、
コアダンプファイルが作成されないようにしておけば、
余計な仕事がかなり減ると思います。

<!--O
Certain kinds of people try to hide files around the system,
usually trying to take advantage of the fact that
files with a leading dot in the name are invisible to the <tt/ls/ command.
One common example are files that look like <tt/.../ that
normally either are not seen,
or, when using <tt/ls -al/ disappear in the noise of normal files
like <tt/./ or <tt/../ that are in every directory.
There is however a countermeasure to this,
use <tt/ls -Al/ that suppresses <tt/./ or <tt/../ but shows all other dot-files.
-->
システムのあちこちに自分のファイルを隠そうとするような人たちもいます。
先頭にドットがつくファイルは <tt/ls/ コマンドでは見えませんので、
この点が良く利用されます。よくある例としては、 <tt/.../ のような
ファイル名です。通常は見えませんし、 <tt/ls -al/ ではすべての
ディレクトリに存在している <tt/./ や <tt/../ にまぎれてしまいます。
これに対する対抗策としては、 <tt/ls -Al/ を使うことです。
このオプションでは <tt/./ と <tt/../ は見えませんが、その他の
ドットファイルは見えるようになります。

<!--O
<sect1>Upgrades
-->
<sect1>システムのアップグレード
<p>
<nidx>disk!maintenance!upgrades</nidx>
<!--O
No matter how large your drives, time will come when you will find you
need more. As technology progresses you can get ever more for your
money. At the time of writing this, it appears that 6.4 GB drives gives
you the most bang for your bucks.
-->
いかに大きなドライブと言えど、いずれは使いきってしまうときがやってきます。
そのころには技術の進歩によるコストパフォーマンスの向上も期待できるでしょう。
現在のところは 6.4 GB クラスが一番良いでしょうか。

<!--O
Note that with IDE drives you might have to remove an old drive, as the
maximum number supported on your mother board is normally only 2 or some
times 4. With SCSI you can have up to 7 for narrow (8-bit) SCSI or up to
15 for wide (15 bit) SCSI, per channel. Some host adapters can support
more than a single channel and in any case you can have more than
one host adapter per system. My personal recommendation is that you will
most likely be better off with SCSI in the long run.
-->
たいていのマザーボードでは IDE は二つ
(あるいは四つ) までしか接続できないので、
IDE ドライブを増設する場合には古いものが無駄になってしまう可能性が高いです。
一方 SCSI は narrow (8 bit) SCSI で 7、 wide (15 bit) SCSI で
15 まで接続できます。
またホストアダプタによっては二つ以上のチャンネルを
サポートしているものもありますし、
場合によっては二つ以上のホストアダプタを一つのシステムに使うこともできます。
筆者の個人的なお勧めですが、長期間に渡って利用するシステムには
SCSI を選択しておく方が良いでしょう。

<!--O
The question comes, where should you put this new drive? In many cases
the reason for expansion is that you want a larger spool area, and in that
case the fast, simple solution is to mount the drive somewhere under
<tt>/var/spool</tt>. On the other hand newer drives are likely to be
faster than older ones so in the long run you might find it worth your
time to do a full reorganizing, possibly using your old design sheets.
-->
ここで問題になるのは、どこに新しいドライブをあてがうかです。
スプール領域の不足が増設の理由になることが多いので、この場合は
<tt>/var/spool</tt> 以下のどこかに
新しいディスクをマウントしてしまえば良いでしょう。
しかし一方、新しいディスクは高速でもあるでしょうから、
長い目で見た場合はシステム全体を再構成する方が良いかもしれません。
その場合は以前に使った設計書が役に立つでしょう。

<!--O
If the upgrade is forced by running out of space in partitions used for
things like <tt>/usr</tt> or <tt>/var</tt> the upgrade is a little more
involved. You might consider the option of a full re-installation from
your favourite (and hopefully upgraded) distribution. In this case you
will have to be careful not to overwrite your essential setups. Usually
these things are in the <tt>/etc</tt> directory. Proceed with care,
fresh backups and working rescue disks. The other possibility is to
simply copy the old directory over to the new directory which is
mounted on a temporary mount point, edit your <tt>/etc/fstab</tt> file,
reboot with your new partition in place and check that it works.
Should it fail you can reboot with your rescue disk, re-edit
<tt>/etc/fstab</tt> and try again.
-->
システムのアップグレードが必要になった原因が <tt>/usr</tt> や 
<tt>/var</tt> などのパーティションの容量の枯渇である場合には、
アップグレードの作業はやや面倒になります。
全体を好みの配布パッケージで
(おそらくこちらもアップグレードされてるでしょうから)
再インストールすることをまず考えてみると良いでしょう。
この場合には、現在の重要な設定を上書きしないように気をつける必要があります。
これらの多くは <tt>/etc</tt> ディレクトリにあるでしょう。
気を付けて作業を進め、
最新のバックアップとレスキューディスクを用意しておくようにしましょう。
もう一つの選択肢もあります。
新しいディレクトリを一時的なポイントにマウントして、
古いディレクトリの内容を単純にコピーします。
次に <tt>/etc/fstab</tt> を編集して新しい方を有効にし、
リブートしてちゃんと動いているかどうかをチェックします。
うまく行かなければレスキューディスクでリブートして 
<tt>/etc/fstab</tt> を再編集し、もう一度トライしましょう。

<!--O
Until volume management becomes available to Linux this is both
complicated and dangerous. Do not get too surprised if you discover
you need to restore your system from a backup.
-->
ボリューム管理が Linux で使えるようになるまでは、
これらの手段はいずれも面倒ですし危険でもあります。
システムをバックアップからレストアするはめになることを覚悟しておくことです。

<!--O
The Tips-HOWTO gives the following example on how to move an entire
directory structure across:
-->
<tt/Tips-HOWTO/ ではディレクトリ構造を丸ごとコピーする方法として、以下
の例を挙げています:
<code>
(cd /source/directory; tar cf - . ) | (cd /dest/directory; tar xvfp -)
</code>

<!--O
While this approach to moving directory trees is portable among many
Unix systems, it is inconvenient to remember. Also, it fails for
deeply nested directory trees when pathnames become to long to
handle for tar (GNU tar has special provisions to deal with long
pathnames).
-->
この手法によるディレクトリ移動は、すべての Unix システムで利用できますが、
覚えておくにはちょっと不便です。またツリーが深くなって、パス名が
tar の扱える長さを越えてしまうと、この作業は失敗してしまいます
(GNU tar では長いパス名も使えるように特別な拡張が施してあります)。

<!--O
If you have access to GNU cp (which is always the case on Linux
systems), you could as well use
-->
GNU の cp を使えるなら (Linux システムなら使えるはず)、
以下でも同じことができます。

<code>
cp -av /source/directory /dest/directory
</code>

<!--O
GNU cp knows specifically about symbolic links, FIFOs and device
files and will copy them correctly.
-->
GNU cp はシンボリックリンクや FIFO, デバイスファイルなどに
関してもちゃんと区別でき、正しくコピーを行えます。

<!--O
Remember that it might not be a good idea to try to transfer
<tt>/dev</tt> or <tt>/proc</tt>.
-->
ただし <tt>/dev</tt> や <tt>/proc</tt> を移動しようとするのは
あまり良い考えではないことも覚えておいてください。

<!--O
There is also a
<url url="http://www.storm.ca/&tilde;yan/Hard-Disk-Upgrade.html"
    name="Hard Disk Upgrade mini-HOWTO">
that gives you a step by step guide on migrating an entire
Linux system, including LILO, form one hard disk to another.
-->
<url url="http://www.storm.ca/&tilde;yan/Hard-Disk-Upgrade.html"
    name="Hard Disk Upgrade mini-HOWTO">
という文書もあり、 LILO を含む Linux システム全体を
別のディスクに移動する手順をステップバイステップで解説しています。


<!--O
<sect1>Recovery
-->
<sect1>復旧
<p>
<nidx>disk!maintenance!recovery</nidx>
<nidx>disk!gpart</nidx>
<nidx>disk!dos tool!findpart</nidx>
<nidx>disk!dos tool!editpart</nidx>
<nidx>disk!dos tool!findfat</nidx>
<nidx>disk!dos tool!getsect</nidx>
<nidx>disk!dos tool!putsect</nidx>
<nidx>disk!dos tool!cyldir</nidx>
<nidx>disk!dos tool!cdir</nidx>
<!--O
System crashes come in many and entertaining flavours, and
partition table corruption always guarantees plenty of excitement.
A recent and undoubtedly useful tool for those of us who
are happy with the normal level of excitement, is
<url url="http://www.stud.uni-hannover.de/user/76201/gpart/"
    name="gpart">
which means "Guess PC-Type hard disk partitions". Useful.
-->
システムのクラッシュは、さまざまな (面白い) かたちでやってきます。
特にパーティションテーブルが破壊されると、
たっぷりスリルを味わうことができます。
心臓の強くない人には、最近とてもとても便利なツールができました。
<url url="http://www.stud.uni-hannover.de/user/76201/gpart/"
    name="gpart">
これは「PC ハードディスクの形式を推定
(Guess PC-Type hard disk partitions)」してくれます。
便利です!

<!--O
In addition there are some
<url url="http://inet.uni2.dk/&tilde;svolaf/utilities.htm"
    name="partition utilities">
available under DOS.
-->
さらに DOS で使える
<url url="http://inet.uni2.dk/&tilde;svolaf/utilities.htm"
    name="パーティションユーティリティ">
もいくつか存在しています。


<!--O
<sect1>Rescue Disk
-->
<sect1>レスキューディスク
<p>
<nidx>disk!maintenance!rescue disk</nidx>
<!--O
Upgrades of kernel and hardware is not uncommon in the Linux world
and it is therefore important that you prepare an updated rescue
disk especially when you use special drivers to access your hardware.
Rescue disks can be gotten off the net, from your distribution or
you can put one together yourself. Do make sure the boot and root
parameters are set so the kernel will know where to find your system.
-->
カーネルやハードウェアのアップデートは、 Linux の世界では
珍しいことではありません。
したがって、最新のレスキューディスクを用意しておくことが重要です。
ハードウェアへのアクセスに特殊なドライバを使う場合にはなおさらです。
レスキューディスクはネットやディストリビューションから入手できますし、
自分で作ることもできます。
boot および root のカーネルパラメータを確認し、
カーネルがシステムをちゃんとブートできるようにしておくのを忘れないように。

<!--O
If you don't have a recovery floppy you can use the
<url url="http://www.gnu.org/software/grub/"
    name="GRUB"> boot loader
to load from a Linux kernel somewhere on disk, with arguments.
-->
復旧フロッピーを持っていない人は、ブートローダである
<url url="http://www.gnu.org/software/grub/"
    name="GRUB">
を用いれば、ディスクのどこかにある
Linux カーネルを引き数を指定してロードできます。


<!--O
<sect>Advanced Issues
-->
<sect>上級者向け情報
<p>
<nidx>disk!advanced topics</nidx>
<!--O
Linux and related systems offer plenty of possibilities for fast, efficient
and devastating destruction. This document is no exception. With power comes
dangers and the following sections describe a few more esoteric issues that
should not be attempted before reading and understanding the documentation,
the issues and the dangers. You should also make a backup. Also remember
to try to restore the system from scratch from your backup at least once.
Otherwise you might not be the first to be found with a perfect backup of
your system and no tools available to reinstall it (or, even more
embarrassing, some critical files missing on tape).
-->
Linux のようなシステムでは、
「高速かつ効果的ではあるが、致命的な破壊をもたらす可能性がある」
手法がたくさんあります。この文書も例外ではありません。
パワーには危険が付きものなのです。
以下のセクションではいくつかの奥義について触れています。
これらは関連文書をしっかり読んで、
危険性を熟知した上で使うようにしてください。
バックアップもとっておくべきでしょう。
バックアップを使ってゼロからシステムを復元できるかどうかも
一度は試しておいてください。
「バックアップはあるけど復元システムがない」と言うようなはめに陥った人は、
過去に何人もいるのです
(あるいはもっと恥ずかしいことには、キーになるファイルがテープにない、とか)。

<!--O
The techniques described here are rarely necessary but can be used for very
specific setups. Think very clearly through what you wish to accomplish
before playing around with this.
-->
ここで述べているテクニックはほとんど必要とはされないでしょうが、
ごく特殊な設定では用いることもできます。
実行する前に、ほんとうに自分がそれを望んでいるかどうかを良く考えてください。

<!--O
For more information read the article
<url url="http://www.linuxforum.com/plug/articles/needforspeed.html"
    name="The Need For Speed">
on tuning with <tt>hdparm</tt>.
-->
<tt>hdparm</tt> を用いたチューニングに関するより詳しい情報を求める方は
<url url="http://www.linuxforum.com/plug/articles/needforspeed.html"
    name="The Need For Speed">
という記事を読んでみましょう。


<!--O
<sect1>Hard Disk Tuning
-->
<sect1>ハードディスクのチューニング
<p>
<nidx>disk!advanced topics!tuning, hard disk</nidx>
<!--O
The hard drive parameters can be tuned using the <tt/hdparms/ utility. Here
the most interesting parameter is probably the read-ahead parameter which
determines how much prefetch should be done in sequential reading.
-->
ハードディスクのパラメータは
<tt/hdparms/ ユーティリティでチューンする事ができます。
最も効果的であろうパラメータとしては read-ahead があります。
これはシーケンシャルな読み込みにおけるプリフェッチの量を指定するものです。

<!--O
If you want to try this out it makes most sense to tune for the
characteristic file size on your drive but remember that this tuning is for
the <em/entire/ drive which makes it a bit more difficult. Probably this is
only of use on large servers using dedicated news drives etc.
-->
これを試してみる場合は、
システムで良く使われているファイルサイズに合わせると、
もっとも効果が高いでしょう。
しかしこの設定はドライブ<em/全体/に用いられるので、
ちょっと難しいことになります。
おそらくこの手法が有効なのは、
大きなサーバでドライブ全体がニュースに用いられている場合などに
限られるでしょう。

<!--O
For safety the default hdparm settings are rather conservative. The
disadvantage is that this mean you can get lost interrupts if you have
a high frequency of IRQs as you would when using the serial port and
an IDE disk as IRQs from the latter would mask other IRQs. This would
be noticeable as less then ideal performance when downloading data from
the net to disk. Setting <tt/hdparm -u1 device/ would prevent this
masking and either improve your performance or, depending on hardware,
corrupt the data on your disk. Experiment with caution and fresh
backups.
-->
安全のため、デフォルトの hdparm の設定はやや保守的になっています。
この設定の欠点は、頻繁に IRQ が飛び交うような環境では
割り込みをロストしてしまう可能性があることです。
例えばシリアルポートと IDE ディスクを両方使っているような場合、
IDE から発行された IRQ は他からの IRQ をマスクしてしまいます。
するとネットからディスクにデータをダウンロードするときなど、
理想的な値から性能が (それとわかるくらいに) 落ちてしまうのです。
このマスク動作をやめるには <tt/hdparm -u1 device/ とします。
性能が上がるかもしれませんが、
ハードウェアによっては逆にディスク上のデータが壊れてしまうかもしれません。
最新のバックアップを取ってから、注意して実験してください。

<!--O
For more information read the article
<url url="http://www.linuxforum.com/plug/articles/needforspeed.html"
    name="The Need For Speed">
on tuning with <tt>hdparm</tt>.
-->
<tt>hdparm</tt> を用いたチューニングに関するより詳しい情報を求める方は
<url url="http://www.linuxforum.com/plug/articles/needforspeed.html"
    name="The Need For Speed">
という記事を読んでみましょう。


<!--O
<sect1>File System Tuning
-->
<sect1>ファイルシステムのチューニング
<p>
<nidx>disk!advanced topics!tuning, filesystem</nidx>
<!--O
Most file systems come with a tuning utility and for <tt/ext2fs/ there is
the <tt/tune2fs/ utility. Several parameters can be modified but perhaps
the most useful parameter here is what size should be reserved and who should
be able to take advantage of this which could help you getting more useful
space out of your drives, possibly at the cost of less room for repairing
a system should it crash.
-->
ほとんどのファイルシステムにはチューニングのためのユーティリティがあります。
<tt/ext2fs/ には <tt/tune2fs/ があります。
変更できるパラメータはいくつかありますが、
最も便利なのは予約領域の大きさと、
それを利用できるユーザを設定するものでしょう。
これによってドライブを余分に使うことができるようになります。
ただしクラッシュしたときに修理用の領域が少なくなるというデメリットもあります。


<!--O
<sect1>Spindle Synchronizing
-->
<sect1>スピンドルを同期させる
<p>
<nidx>disk!advanced topics!spindle synchronization</nidx>
<!--O
This should not in itself be dangerous, other than the peculiar fact that
the exact details of the connections remain unclear for many drives. The
theory is simple: keeping a fixed phase difference between the different
drives in a RAID setup makes for less waiting for the right track to come
into position for the read/write head. In practice it now seems that with
large read-ahead buffers in the drives the effect is negligible.
-->
この方法そのものは危険ではありません。
ただし特定の要素が絡むとまずいこともあるようです。
多くのドライブでは、このあたりの詳細ははっきりしていません。
理論は単純で、 RAID を組んでいるディスク間で位相の差を一定に保っておけば、
リクエストのあったトラックに読み書きを行うヘッドが到達するまでの時間を
短くできるだろう、というものです。
実際には、最近のドライブには大きな先読みバッファがあるので、
この効果は無視できるくらい小さくなったようです。

<!--O
Spindle synchronisation should not be used on RAID0 or RAID 0/1 as you
would then lose the benefit of having the read heads over different
areas of the mirrored sectors.
-->
スピンドルの同期は RAID 0 や RAID 0/1 では用いるべきではありません。
なぜならミラーされたセクタの別々の領域に、それぞれの読み取りヘッドを
配置できるという利点が失われてしまうからです。


<!--O
<sect>Troubleshooting <label id="troubleshooting">
-->
<sect>トラブルシュート<label id="troubleshooting">
<p>
<nidx>disk!troubleshooting</nidx>
<!--O
Much can go wrong and this is the start of a growing list of symptoms,
problems and solutions:
-->
世の中はうまくいかないことが往々にしてあるものです。
ということで、ここに症状・問題・解決法のリストを作っていきたいと思います。

<!--O
<sect1>During Installation
-->
<sect1>インストール中

<!--O
<sect2>Locating Disks
-->
<sect2>ディスクの配置
<p>
<descrip>
<!--O
<tag/Symptoms/Cannot find disk
<tag/Problem/How to find what drive letter corresponds to what disk/partition
<tag/Solution/Remember Linux does not use drive letters but device names. More
information can be found in <ref id="drive-names" name="Drive names">.
-->
<tag/症状/ ディスクが見つからない。
<tag/問題/ どのドライブレターがどのディスク/パーティションに対応するのか
わからない。
<tag/解決法/ Linux はドライブレターの代わりにデバイス名を使います。
詳細は <ref id="drive-names" name="ドライブ名"> を見てください。
</descrip>
<p>
<descrip>
<!--O
<tag/Symptoms/Cannot format disk
<tag/Problem/Most likely wrong input to the command line for <tt/fdisk/ or similar tool.
<tag/Solution/Remember to use <tt>/dev/hda</tt> rather than just <tt>hda</tt>. Also
do not use numbers behind <tt>hda</tt>, those indicate partitions.
-->
<tag/症状/ ディスクをフォーマットできない。
<tag/問題/ ほとんどの場合は <tt/fdisk/ などのツールでの入力ミス。
<tag/解決法/ 単に <tt/hda/ と入力するのではなく、<tt>/dev/hda</tt>
と入力します。また <tt/hda/ の後には番号をつけないように。
つけるとパーティションを指すことになります。
</descrip>


<!--O
<sect2>Formatting
-->
<sect2>フォーマット
<p>
<descrip>
<!--O
<tag/Symptoms/Cannot partition disk.
<tag/Problem/Strictly speaking you format partitions not disks.
<tag/Solution/Make sure you add the partition number after the device name
of the disk, for instance <tt>/dev/hda1</tt> to the command line.
-->
<tag/症状/ ディスクをフォーマットできない。
<tag/問題/ フォーマットできるのはディスクではなくパーティション。
<tag/解決法/ フォーマットの対象をコマンドラインから指定する際、
ディスクのデバイス名の後にパーティション番号をつけるように
してください。 <tt>/dev/hda1</tt> のようになります。
</descrip>



<!--O
<sect1>During Booting
-->
<sect1>ブート中

<!--O
<sect2>Booting fails
-->
<sect2>ブートに失敗する
<p>
<descrip>
<!--O
<tag/Symptoms/ Number keep scrolling up the screen.
<tag/Problem/ Possibly corrupt disk.
<tag/Solution/ Try another disk, you might have to reinstall. Check for
loose cables and possible data corruption.
-->
<tag/症状/ 数字が画面に表示され続ける。
<tag/問題/ おそらくディスクに問題がある。
<tag/解決法/ 別のディスクを試してください。
再インストールしなければならないかも知れません。
ケーブルが緩んでいないか、データが壊れていないかも確認してください。
</descrip>
<p>
<descrip>
<!--O
<tag/Symptoms / Get <tt/LI/ and then it hangs.
<tag/Problem/You use LILO to load Linux but LILO cannot find your root.
<tag/Solution/ Read the LILO HOWTO.
-->
<tag/症状/ <tt/LI/ が表示されてハングアップする。
<tag/問題/ linux のロードに LILO が使われているが、 LILO が root
を見つけられない。
<tag/解決法/ LILO HOWTO を読んでください。
</descrip>
<p>
<descrip>
<!--O
<tag/Symptoms/Kernel panics, something about missing root file system.
<tag/Problem/The kernel does not know where the root partition is.
<tag/Solution/Use <tt/rdev/ or (if applicable) LILO to add information
to the kernel image where your root is.
-->
<tag/症状/ カーネルが、 root ファイルシステムがないといって panic になる。
<tag/問題/ カーネルが root パーティションの場所を知らない。
<tag/解決法/ <tt/rdev/ や (可能なら) LILO を使って、
カーネルイメージに root の場所の情報を追加してください。
</descrip>


<!--O
<sect2>Getting into Single User Mode
-->
<sect2>シングルユーザーモードになる。
<p>
<descrip>
<!--O
<tag/Symptoms/System boots but get into a root shell in single user mode.
<tag/Problem/Something went wrong in the later stages of booting and the
system has come far enough to let you open a shell to repair the system.
<tag/Solution/Locate the problems from the boot log. Note that file system
can be in read-only mode. Remount read-write if you have to. Often the
reason is that the <tt>/etc/fstab</tt> contained an entry that was mismapped
such as trying to mount a swap partition as your normal file space.
-->
<tag/症状/ システムはブートするが、シングルユーザーモードで
root のシェルが起動する。
<tag/問題/ ブートの終盤で何か問題が生じた。
シェルを開いてシステムを修復可能なところまでは来ている。
<tag/解決法/ ブートのログから問題を見つけてください。
ファイルシステムはリードオンリーになっているかもしれませんので、
必要な場合は読み書きモードで再マウントしてください。
<tt>/etc/fstab</tt> に問題のあるエントリがあるような場合が多いようです
(スワップパーティションを通常のファイル空間にマウントしようとしているなど)。
</descrip>


<!--O
<sect1>During Running
-->
<sect1>動作中

<!--O
<sect2>Swap
-->
<sect2>スワップ
<p>
<descrip>
<!--O
<tag/Symptoms/Short on memory
<tag/Problem/Swap space is not available
<tag/Solution/Type free and check the output. If you get
<tscreen><verb>
             total       used       free     shared    buffers     cached
Mem:         46920      30136      16784       7480      11788       5764
-/+ buffers/cache:      12584      34336
Swap:       128484       9176     119308
</verb></tscreen>
then system is running normal. If the line with <tt/Swap:/ contains zeros
you have either not mounted the swap space (partition or swap file)
(see <tt>swapon(8)</tt>)
or not formatted the swap space (see <tt>mkswap(8)</tt>).
-->
<tag/症状/ メモリが足りなくなった。
<tag/問題/ スワップが有効になっていない。
<tag/解決法/ free と入力して出力を調べてください。
<tscreen><verb>
             total       used       free     shared    buffers     cached
Mem:         46920      30136      16784       7480      11788       5764
-/+ buffers/cache:      12584      34336
Swap:       128484       9176     119308
</verb></tscreen>
のようになっていれば、システムは問題なく動作しています。
<tt/Swap:/ の行が 0 になっている場合は、スワップ
(パーティションまたはスワップファイル) をマウントしていない
(<tt/swapon(8)/ を見よ)、スワップをフォーマットしていない
(<tt/mkswap(8)/ を見よ) などが考えられます。
</descrip>



<!--O
<sect2>Partitions
-->
<sect2>パーティション
<p>
<descrip>
<!--O
<tag/Symptoms/No room amidst plenty 1
<tag/Problem/Partitionitis:Underdimensioned partition sizes
has caused overflow in some areas
<tag/Solution/Examine your partition usage using <tt>df(1)</tt> and locate
problem areas. Normally the problem can be solved by removing old junk but
you might have to repartition your system,
see section <ref id="repartitioning" name="Repartitioning">.
-->
<tag/症状/No room amidst plenty 1
<tag/問題/オーバーパーティション症候群:
パーティションサイズが小さすぎるどこかの領域がオーバーフローを起こしている。
<tag/解決法/パーティションの利用状況を <tt/df(1)/ で調べ、
問題のある領域を特定してください。
問題のある部分を削除すれば解決することが多いですが、
システムを再パーティションしなければならないかもしれません。
<ref id="repartitioning" name="再パーティション">
の章を見てください。
</descrip>
<p>
<descrip>
<!--O
<tag/Symptoms/No room amidst plenty 2
<tag/Problem/Running out of i-nodes has caused overflow in some ares,
often in areas with many small files such as news spool.
<tag/Solution/Examine your partition usage using <tt>df -i</tt> and locate
problem areas. Normally the problem is solved by reformatting using
a higher number of i-nodes, see <tt>mkfs(8)</tt> and related man pages.
-->
<tag/症状/No room amidst plenty 2
<tag/問題/どこかの領域で i ノードが使い果たされてしまった。
ニューススプールのような、
小さなファイルがたくさん置かれる領域であることが多い。
<tag/解決法/ パーティションの利用状況を
<tt/df -i/ で調べ、問題のある領域を特定してください。
通常は、 i ノードを増やしてその領域を再フォーマットすれば解決します。
<tt/mkfs(8)/ や、関連する man ページを見てください。
</descrip>

<!--

<sect2>
<p>
<descrip>
<tag/Symptoms/
<tag/Problem/
<tag/Solution/
</descrip>

-->


<!--O
<sect>Further Information
-->
<sect>この文書以外の情報
<p>
<nidx>disk!information resources</nidx>
<!--O
There is wealth of information one should go through when setting up a
major system, for instance for a news or general Internet service provider. 
The FAQs in the following groups are useful:
-->
巨大なシステムをセットアップする場合などに見ておくべき情報は、
他にもたくさんあります。例えばニュース、
一般のインターネットプロバイダなどです。
以下のニュースグループにおける FAQ も役に立ちます。

<!--O
<sect1>News groups
-->
<sect1>ニュースグループ
<p>
<nidx>disk!information resources!news groups</nidx>
<!--O
Some of the most interesting news groups are:
-->
特に面白いグループとしては、以下のようなものがあります。
<itemize>
<item><url url="news:comp.arch.storage"                   name="Storage">.
<item><url url="news:comp.sys.ibm.pc.hardware.storage"    name="PC storage">.
<item><url url="news:alt.filesystems.afs"                 name="AFS">.
<item><url url="news:comp.periphs.scsi"                   name="SCSI">.
<item><url url="news:comp.os.linux.setup"                 name="Linux setup">.
</itemize>

<!--O
Most newsgroups have their own FAQ that are designed to answer most of your
questions, as the name Frequently Asked Questions indicate. Fresh versions
should be posted regularly to the relevant newsgroups. If you cannot find it
in your news spool you could go directly to the
<url url="ftp://rtfm.mit.edu"
    name="FAQ main archive FTP site">. The WWW versions can be browsed at
<!-\- <url url="http://www.cis.ohio-state.edu/hypertext/faq/usenet/FAQ-List.html" 000501 -\->
<url url="http://www.faqs.org/faqs/FAQ-List.html"
    name="FAQ main archive WWW site">.
-->
ほとんどのニュースグループには対応する FAQ が存在し、その名の通り、
ほとんどの質問に答えてくれるでしょう。
最新のバージョンは定期的にそのニュースグループにポストされるはずです。
ニューススプールになかった場合は
<url url="ftp://rtfm.mit.edu"
    name="FAQ main archive FTP site">
を見てみましょう。 WWW 版も
<url url="http://www.faqs.org/faqs/FAQ-List.html"
    name="FAQ main archive WWW site">
から見ることができます。

<!--O
Some FAQs have their own home site, of particular interest here are
<itemize>
<item><url url="http://www.scsifaq.org/"
          name="SCSI FAQ"> and
<item><url url="http://alumni.caltech.edu/&tilde;rdv/comp&lowbar;arch&lowbar;storage/FAQ-1.html"
          name="comp.arch.storage FAQ">.
</itemize>
-->
FAQ によっては独自のホームサイトが用意されているものもあります。
この文書に関連するものとしては以下を挙げておきます。
<itemize>
<item><url url="http://www.scsifaq.org/"
          name="SCSI FAQ">
<item><url url="http://alumni.caltech.edu/&tilde;rdv/comp-arch-storage/FAQ-1.html"
          name="comp.arch.storage FAQ">.
</itemize>


<!--O
<sect1>Mailing Lists
-->
<sect1>メーリングリスト
<p>
<nidx>disk!information resources!mailing lists</nidx>
<!--O
These are low noise channels mainly for developers. Think
twice before asking questions there as noise delays the development.
Some relevant lists are <tt/linux-raid/, <tt/linux-scsi/ and <tt/linux-ext2fs/.
Many of the most useful mailing lists run on the <tt>vger.rutgers.edu</tt> server
but this is notoriously overloaded, so try to find a mirror. There are some lists mirrored at
<url url="http://www.redhat.com"
    name="The Redhat Home Page">.
Many lists are also accessible at
<url url="http://www.linuxhq.com/lnxlists/"
    name="linuxhq">,
and the rest of the web site is a gold mine of useful information.
-->
これは主に開発者向けの、ノイズ発言の少ないチャンネルです。
ここに質問をする前には 2 回考えなおしてみること。
ノイズは開発を遅らせてしまうからです。
関連したリストとしては <tt/linux-raid/, <tt/linux-scsi/, <tt/linux-ext2fs/
などがあります。
このような非常に有用なメーリングリストが、
<tt>vger.rutgers.edu</tt> サーバにはたくさんあります。
しかしここは非常に負荷が高くなっているので、ミラーを探してみましょう。
いくつかのリストが
<url url="http://www.redhat.com"
    name="The Redhat Home Page">
でミラーされています。多くのリストは
<url url="http://www.kernelnotes.org/"
    name="kernelnotes.org">
でもアクセスできます。
この web サイトにある他のページも有用な情報の宝の山です。

<!--O
If you want to find out more about the lists available you can send a message
with the line <tt/lists/ to the list server at vger.rutgers.edu (
<htmlurl url="mailto:majordomo@vger.rutgers.edu"
        name="majordomo@vger.rutgers.edu">).
If you need help on how to use the mail server just send the line <tt/help/
to the same address.
Due to the popularity of this server it is likely it takes a bit to time before
you get a reply or even get messages after you send a <tt/subscribe/ command.
-->
利用できるリストについてもっと知りたい場合は、
<tt/lists/ という一行を書いたメッセージを
vger.rutgers.edu のリストサーバ
<htmlurl url="mailto:majordomo@vger.rutgers.edu"
        name="majordomo@vger.rutgers.edu">
に送ってください。メールサーバの使い方がわからない場合は、このアドレスに
<tt/help/ とだけ書いて送ってください。
このサーバは人気が高いので、返事が来るまでには多少時間がかかるかもしれません。
また <tt/subscribe/ コマンドを送ってからメールが配信されるまでにも、
同じように時間がかかるかもしれません。

<!--O
There is also a number of other majordomo list servers that can be of interest
such as the EATA driver list (
<htmlurl url="mailto:linux-eata@mail.uni-mainz.de"
        name="linux-eata@mail.uni-mainz.de">)
and the Intelligent IO list
<htmlurl url="mailto:linux-i2o@dpt.com"
        name="linux-i2o@dpt.com">.
-->
majordomo のリストサーバには、他にも面白いものがあります。
たとえば EATA driver list
(<htmlurl url="mailto:linux-eata@mail.uni-mainz.de"
        name="linux-eata@mail.uni-mainz.de">)
や Intelligent IO list
(<htmlurl url="mailto:linux-i2o@dpt.com"
        name="linux-i2o@dpt.com">)
などが挙げられるでしょう。

<!--O
Mailing lists are in a state of flux but you can find links to a number of
interesting lists from the
<url url="http://www.linuxdoc.org/"
    name="Linux Documentation Homepage">.
-->
メーリングリストというものは常に流動的ですが、
多くの興味深いリストが
<url url="http://www.linuxdoc.org/"
    name="Linux Documentation Homepage">
からリンクされています。


<sect1>HOWTO
<p>
<nidx>disk!information resources!HOWTOs</nidx>
<!--O
These are intended as the primary starting points to
get the background information as well as show you how to solve
a specific problem.
Some relevant HOWTOs are <tt/Bootdisk/, <tt/Installation/,  <tt/SCSI/ and <tt/UMSDOS/.
The main site for these is the
<url url="http://www.linuxdoc.org/"
    name="LDP archive">.
<!-\- at Metalab (formerly known as Sunsite). -\->
-->
これらは、ユーザが背景知識を得るための出発点となることを意図して
書かれている文書です。特定の問題に関する解答を示すこともあります。
関連する HOWTO としては <tt/Bootdisk/, <tt/Installation/, <tt/SCSI/,
<tt/UMSDOS/ などがあります。これらのメインサイトは、
<url url="http://www.linuxdoc.org/"
    name="LDP アーカイブ">
です。

<!--O
There is a a new HOWTO out that deals with setting up a
DPT RAID system, check out the
<url url="http://www.ram.org/computing/linux/dpt&lowbar;raid.html"
    name="DPT RAID HOWTO homepage">.
-->
DPT RAID システムの設定を扱う新しい HOWTO も公開されました。
<url url="http://www.ram.org/computing/linux/dpt&lowbar;raid.html"
    name="DPT RAID HOWTO homepage">
をチェックしてみましょう。



<sect1>Mini-HOWTO
<p>
<nidx>disk!information resources!mini-HOWTOs</nidx>
<!--O
These are the smaller free text relatives to the HOWTOs.
Some relevant mini-HOWTOs are
<tt/Backup-With-MSDOS/, <tt/Diskless/, <tt/LILO/, <tt/Large Disk/,
<tt/Linux+DOS+Win95+OS2/, <tt/Linux+OS2+DOS/, <tt/Linux+Win95/,
<tt/NFS-Root/, <tt/Win95+Win+Linux/, <tt/ZIP Drive/ .
You can find these at the same place as the HOWTOs, usually in a sub directory
called <tt/mini/. Note that these are scheduled to be converted into SGML and
become proper HOWTOs in the near future.
-->
HOWTO に比べ少々小さな文書で、テキスト形式で書かれていることも
多いです。関連する mini-HOWTO 文書としては、
<tt/Backup-With-MSDOS/, <tt/Diskless/, <tt/LILO/, <tt/Large Disk/
<tt/Linux+DOS+Win95+OS2/, <tt/Linux+OS2+DOS/, <tt/Linux+Win95/,
<tt/NFS-Root/, <tt/Win95+Win+Linux/, <tt/ZIP Drive/
などが挙げられます。これらは HOWTO と同じところから入手できます。
通常は <tt/mini/ というサブディレクトリに置かれています。
これらは近い将来には SGML に変換され、 mini のつかない HOWTO に
なる予定です。

<!--O
The old <tt/Linux Large IDE mini-HOWTO/ is no longer valid, instead read
<tt>/usr/src/linux/drivers/block/README.ide</tt> or
<tt>/usr/src/linux/Documentation/ide.txt</tt>.
-->
<tt/Linux Large IDE mini-HOWTO/ は古いので、もう正しくありません。
代わりに
<tt>/usr/src/linux/drivers/block/README.ide</tt> または
<tt>/usr/src/linux/Documentation/ide.txt</tt>
を読みましょう。

訳注: 以上の HOWTO, mini-HOWTO 文書のいくつかは、
<url url="http://www.linux.or.jp/JF/" name="JF プロジェクト">
より日本語訳が入手できます。

<!--O
<sect1>Local Resources
-->
<sect1>ローカルな情報源
<p>
<nidx>disk!information resources!local</nidx>
<!--O
In most distributions of Linux there is a document directory installed,
have a look in the
<htmlurl url="file:///usr/doc"
    name="/usr/doc"> directory.
where most packages store their main documentation and README files etc.
Also you will here find the HOWTO archive (
<htmlurl url="file:///usr/doc/HOWTO"
    name="/usr/doc/HOWTO">)
of ready formatted HOWTOs
and also the mini-HOWTO archive (
<url url="file:///usr/doc/HOWTO/mini"
    name="/usr/doc/HOWTO/mini">)
of plain text documents.
-->
Linux のほとんどのディストリビューションには、すでに文書ディレクトリが
存在しているはずです。
<htmlurl url="file:///usr/doc"
     name="/usr/doc">
を見てみましょう。ほとんどのパッケージが、
主要な文書や README ファイルなどをこのディレクトリ以下に配置しています。
ここの
<htmlurl url="file:///usr/doc/HOWTO"
     name="/usr/doc/HOWTO">
には整形済みの HOWTO があるはずですし、
<htmlurl url="file:///usr/doc/HOWTO/mini"
     name="/usr/doc/HOWTO/mini">
にはプレインテキストの文書があるはずです。

<!--O
Many of the configuration files mentioned earlier can be found in the
<htmlurl url="file:///etc"
    name="/etc">
directory. In particular you will want to work with the
<htmlurl url="file:///etc/fstab"
    name="/etc/fstab">
file that sets up the mounting of partitions
and possibly also
<htmlurl url="file:///etc/mdtab"
    name="/etc/mdtab">
file that is used for the <tt/md/ system to set up RAID.
-->
これまでに紹介してきた設定ファイルの多くは
<htmlurl url="file:///etc"
    name="/etc">
ディレクトリにあります。特に作業する必要がありそうなのは
<htmlurl url="file:///etc/fstab"
    name="/etc/fstab">
ファイルでしょう。これはパーティションのマウント情報を扱います。
また <tt/md/ を用いて RAID を設定するには
<htmlurl url="file:///etc/mdtab"
    name="/etc/mdtab">
ファイルを使います。

<!--O
The kernel source in
<url url="file:///usr/src/linux"
    name="/usr/src/linux">
is, of course, the ultimate documentation. In other
words, <em>use the source, Luke</em>.
It should also be pointed out that the kernel comes not only with
source code which is even commented (well, partially at least)
but also an informative
<url url="file:///usr/src/linux/Documentation"
    name="documentation directory">.
If you are about to ask any questions about the kernel you should
read this first, it will save you and many others a lot of time
and possibly embarrassment.
-->
<htmlurl url="file:///usr/src/linux"
    name="/usr/src/linux">
以下のカーネルソースは、もちろん究極のドキュメントです。
別の言い方をしましょうか。
「<em/ルークよ、ソースを使え/ (<em/use the source, Luke/)」
カーネルのアーカイブには、
ソースコード (とそれに付属する少なくとも最低限のコメント) だけでなく、
文書が置かれたディレクトリ
<htmlurl url="file:///usr/src/linux/Documentation"
    name="/usr/src/linux/Documentation">
が含まれていることも紹介しておきましょう。
カーネルに関する質問をする前には、これらをまず読むことです。
あなた自身や、他の多くの人たちの時間を節約することになりますし、
恥をかかずにすむかもしれません。

<!--O
Also have a look in your system log file (
<htmlurl url="file:///var/log/messages"
    name="/var/log/messages">)
to see what is going on and in particular how the booting went if
too much scrolled off your screen. Using <tt>tail -f /var/log/messages</tt>
in a separate window or screen will give you a continuous update of what is
going on in your system.
-->
システムのログファイル
<htmlurl url="file:///var/log/messages"
    name="/var/log/messages">
も見ておきましょう。何が動作しているか、
特にブートがどのように行われているかがわかります
 (スクリーンはスクロールアウトしちゃいますからね)。
別のウィンドウやスクリーンで <tt>tail -f /var/log/messages</tt>
すれば、システムに起こっていることを継続して監視できます。

<!--O
You can also take advantage of the 
<htmlurl url="file:///proc"
    name="/proc">
file system that is a window into the inner workings of your system.
Use <tt/cat/ rather than <tt/more/ to view the files as they are 
reported as being zero length. Reports are that <tt/less/ works well here.
-->
<htmlurl url="file:///proc"
    name="/proc">
ファイルシステムからも有用な情報が得られるでしょう。
ここは動作しているシステム内部へののぞき窓なのです。
ここにあるファイルを見るには <tt/more/ ではなく <tt/cat/ を使いましょう。
前者では、これらは大きさゼロのファイルとして扱われてしまうからです。
<tt/less/ ならうまく見える、という報告もありました。

<!-- removed 221198
Much of the work here is based on the Filesystem Structure Standard (FSSTND).
It has changed name to File Hierarchy Standard (FHS) and is less Linux
specific.
The maintainer has set up a
<url url="http://www.pathname.com/fhs"
    name="home page">
which tells you how to join the currently private mailing list,
where the development takes place.
 -->


<!--O
<sect1>Web Pages
-->
<sect1>Web ページ
<p>
<nidx>disk!information resources!WWW</nidx>
<nidx>disk!information resources!web pages</nidx>
<!--O
There is a huge number of informative web pages out there and by their very
nature they change quickly so don't be too surprised if these links become
quickly outdated.
-->
情報に満ちた web ページは山ほどあります。
その性質上、 web ページは頻繁に変わるので、
ここに書いたリンクが古くなっていてもどうかあまり驚かないでください。

<!--O
A good starting point is of course the
<url url="http://www.linuxdoc.org/"
    name="Linux Documentation Homepage">.
that is a information central for documentation, project pages and much, much more.
-->
よい出発点は、もちろん
<url url="http://www.linuxdoc.org/"
    name="Linux Documentation Homepage">.
でしょう。ここは文書やプロジェクトのページ、
その他諸々に関する情報の中心です。


<itemize>
<!--O
<item>Mike Neuffer, the author of the DPT caching RAID controller drivers, has some
interesting pages on
-->
<item>DPT キャッシング RAID コントローラのドライバを書いた
Mike Neuffer が興味深いページをいくつか公開しています。

<!-- Old links updated 971021
<url url="http://www.i-connect.net/&tilde;mike/scsi"
    name="SCSI">
and
<url url="http://www.i-connect.net/&tilde;mike/scsi/dpt"
    name="DPT">.
 -->

<!--O
<url url="http://www.uni-mainz.de/&tilde;neuffer/scsi/"
    name="SCSI">
and
<url url="http://www.uni-mainz.de/&tilde;neuffer/scsi/dpt/"
    name="DPT">.
-->
<url url="http://www.uni-mainz.de/&tilde;neuffer/scsi/"
    name="SCSI のページ">
と
<url url="http://www.uni-mainz.de/&tilde;neuffer/scsi/dpt/"
    name="DPT のページ"> です。

<!--O
<item>Software RAID development information can be found at
<url url="http://www.kernel.org/"
    name="Linux Kernel site">
along with patches and utilities.
-->
<item>ソフトウェア RAID の開発に関する情報は
<url url="http://www.kernel.org/"
    name="Linux Kernel site">
にあります。パッチやユーティリティもここにあります。

<!--O
<item>Disk related information on benchmarking, RAID, reliability and
much, much more can be found at
<url url="http://linas.org"
    name="Linas Vepstas">
project page.
-->
<item>ベンチマーク、 RAID、信頼性、その他にも数多くのディスク関連情報が
<url url="http://linas.org"
    name="Linas Vepstas">
プロジェクトのページにあります。

<!--O
<item>There is also information available on how to
<url url="ftp://ftp.bizsystems.com/pub/raid/Root-RAID-HOWTO.html"
    name="RAID the root partition">
and what software packages are needed to achieve this.
-->
<item>ルートパーティションを RAID にする方法や、これを行うために
必要なソフトウェアなどの情報は
<url url="ftp://ftp.bizsystems.com/pub/raid/Root-RAID-HOWTO.html">
から入手できます。

<!--O
<item>In depth documentation on
<url url="http://step.polymtl.ca/&tilde;ldd/ext2fs/ext2fs&lowbar;toc.html"
    name="ext2fs">
is also available.
-->
<item><tt/ext2fs/ に関する詳細な情報が
<url url="http://step.polymtl.ca/&tilde;ldd/ext2fs/ext2fs&lowbar;toc.html">
から入手できます。

<!-- moved 990126
<item>Mark D. Roth has information on
<url url="http://www.uiuc.edu/ph/www/roth"
    name="VPS">
 -->

<!-- moved
<item>A similar kind of project on an
<url url="http://www.virtual.net.au/&tilde;rjh/enh-fs.html"
    name="Enhanced File System">  -->

<!--O
<item>People who looking for information on VFAT, FAT32 and Joliet
could have a look at the
<url url="http://bmrc.berkeley.edu/people/chaffee/index.html"
    name="development page">.
-->
<item>VFAT, FAT32, Joliet に関する情報を探している人は、
<url url="http://bmrc.berkeley.edu/people/chaffee/index.html"
    name="開発ページ">
を見てください。

<!-- Only minor details are missing before it comes into the kernel. -->
<!--O
These drivers are in the 2.1.x kernel development series as well as
in 2.0.34 and later.
-->
これらのドライバは 2.1.x の開発版カーネルや
2.0.34 以降のカーネルに取り込まれています。

<!-- seems to be gone 001117
<item>For more information on booting and also some BSD information
have a look at
<url url="http://www.paranoia.com/&tilde;vax/boot.html"
    name="booting information">
page. -->
<!--O
<item>ブートに関する情報や BSD に関する情報は
<url url="http://www.paranoia.com/~vax/boot.html"
    name="booting information">
のページにあります。
-->

</itemize>

<!--O
For diagrams and information on all sorts of disk drives, controllers etc. both
for current and discontinued lines
<url url="http://theref.aquascape.com/theref.html"
    name="The Ref">
is the site you need. There is a lot of useful information here, a real treasure trove.
-->
あらゆるディスクドライブやコントローラなどに関する仕様・情報は、
新しいものも古いものも
<url url="http://theref.aquascape.com/theref.html"
    name="The Ref">
から入手できます。ここには有用な情報が本当にたくさんあります。
まさに宝の山です。

<!--
You can also download the database using
<url url="ftp://theref.c3d.rl.af.mil/public"
    name="FTP">.
 -->

<!--O
Please let me know if you have any other leads that can be of interest.
-->
他にも興味深いサイトがあったら筆者まで教えてください。


<!--O
<sect1>Search Engines
-->
<sect1>検索エンジン
<p>
<nidx>disk!information resources!search engines</nidx>
<nidx>disk!information resources!Troubleshooting mini-HOWTO</nidx>
<nidx>disk!information resources!Updated mini-HOWTO</nidx>
<!--

<!-\-O
Remember you can also use the web search engines and that some, like
-\->
以下のような検索エンジンを使うこともできます。
<itemize>
<item><url url="http://www.altavista.digital.com"
    name="Altavista">

<item><url url="http://www.excite.com"
    name="Excite">

<item><url url="http://www.hotbot.com"
    name="Hotbot">
</itemize>
<!-\-O
can also search Usenet News.
-\->

これらでは Usenet ニュースの検索もできます。

<!-\-O
Also remember that
<url url="http://www.deja.com"
    name="Deja">, formerly known as Dejanews,
is a dedicated news searcher that keeps a news spool
from early 1995 and onwards.
-\->
<url url="http://www.deja.com"
    name="Deja"> (以前の Dejanews)
も覚えておきましょう。ここはニュース検索用のサイトで、
1995 初期以降のニュースを保存しています。
 -->

<!--O
When all fails try the internet search engines. There is a huge number
of them, all a little different from each other. It falls outside the
scope of this HOWTO to describe how best to use them. Instead you
could turn to the Troubleshooting on the Internet mini-HOWTO, and the
Updated mini-HOWTO.
-->
どこにもなければインターネットの検索エンジンを試してみましょう。
たくさん種類があり、それぞれ少しづつ機能が違っています。
これらをいかにフル活用するかに関しては、
この HOWTO の目的から外れていますので述べません。
Internet mini-HOWTO のトラブルシュートの章や、
Updated mini-HOWTO などをご覧ください。

<!--O
If you have to ask for help you are most likely to get help in the
<url url="news:comp.os.linux.setup"
    name="Linux Setup">
news group.
Due to large workload and a slow network connection I am not able to
follow that newsgroup so if you want to contact me you have to do so
by e-mail.
-->
助けを求めたい場合は、
<htmlurl url="news:comp.os.linux.setup"
    name="comp.os.linux.setup">
ニュースグループが良いでしょう。
私自身は、多忙なためと、ネットワーク接続が遅いために、
このニュースグループはフォローできていません。
私に連絡したい場合は電子メールを使ってください。

<!--O
<sect>Getting Help
-->
<sect>助けを求めるには
<p>
<!-- New 971006 -->
<nidx>disk!assistance, obtaining</nidx>

<!--O
In the end you might find yourself unable to solve your problems and need
help from someone else. The most efficient way is either to ask someone
local or in your nearest Linux user group, search the web for the nearest
one.
-->
いろいろと試しても、自力だけでは問題を解決できないこともあるでしょう。
この場合は他の人に助けてもらわなければなりません。
もっとも効率の良い方法は、近くにいる人や、
近所の Linux ユーザグループに尋ねたり、
あるいは近くの web を検索することです。

<!--O
Another possibility is to ask on Usenet News in one of the many, many
newsgroups available. The problem is that these have such a high
volume and noise (called low signal-to-noise ratio) that your question
can easily fall through unanswered.
-->
他の可能性として、
たくさんある Usenet ニュースグループのどこかで尋ねることもできます。
この方法の問題は、これらのグループでは流量もノイズも大きい
(S/N 比が低い、と言われます) ために、
あなたの質問が答えられないまま放っておかれる可能性が高いことです。

<!--O
No matter where you ask it is important to ask well or you will not be
taken seriously. Saying just <it/my disk does not work/ is not going
to help you and instead the noise level is increased even further and if
you are lucky someone will ask you to clarify.
-->
どこで尋ねるにしろ、真面目に取り合ってもらうためには、
上手に質問することが大事です。
「僕のディスクが動きません」
なんて言うだけじゃ誰も助けてくれないでしょうし、
ノイズのレベルがまた上がるだけの結果になります。
運が良ければ誰かが詳しい内容を尋ねてくれるかもしれませんけど。

<!--O
Instead describe your problems in some detail that
will enable people to help you. The problem could lie somewhere you did
not expect. Therefore you are advised to list up the following information
on your system:
-->
そうではなく、あなたの問題をできるだけ詳細に述べて、
他の人があなたを助けることができるようにするべきです。
問題の原因はあなたが思っているのとは違うところにあるのかもしれません。
ですから、あなたのシステムに関する以下のような情報を列記すべきなのです。

<descrip>
<!--O
<tag/Hardware/
<itemize>
<item>Processor
<item>DMA
<item>IRQ
<item>Chip set (LX, BX etc)
<item>Bus (ISA, VESA, PCI etc)
<item>Expansion cards used (Disk controllers, video, IO etc)
</itemize>
-->
<tag/ハードウェア/
<itemize>
<item>プロセッサ
<item>DMA
<item>IRQ
<item>チップセット (LX, BX など)
<item>バス (ISA, VESA, PCI など)
<item>使っている拡張カード (ディスクコントローラ、ビデオ、IO など)
</itemize>

<!--O
<tag/Software/
<itemize>
<item>BIOS (On motherboard and possibly SCSI host adapters)
<item>LILO, if used
<item>Linux kernel version as well as possible modifications and patches
<item>Kernel parameters, if any
<item>Software that shows the error (with version number or date)
</itemize>
-->
<tag/ソフトウェア/
<itemize>
<item>BIOS (マザーボードの。 SCSI ホストアダプタにもあるかも)
<item>使っている場合は LILO
<item>Linux kernel のバージョンと、修正パッチなど
<item>指定している場合はカーネルのパラメータ
<item>エラーを発しているソフトウェア (バージョンと日付も)
</itemize>

<!--O
<tag/Peripherals/
<itemize>
<item>Type of disk drives with manufacturer name, version and type
<item>Other relevant peripherals connected to the same busses
</itemize>
-->
<tag/周辺機器/
<itemize>
<item>ディスクドライブの形式、製造会社の名前、バージョン
<item>同じバスに繋がっている他の周辺機器
</itemize>

</descrip>

<!--O
As an example of how interrelated these problems are: an old chip set caused
problems with a certain combination of video controller and SCSI host adapter.
-->
これらの問題がどのように相関しているかの一例を挙げてみましょう。
古いチップセットでは、
ビデオコントローラと SCSI ホストアダプタの組み合わせによっては
障害が起こることがあったりするのです。

<!--O
Remember that booting text is logged to <tt>/var/log/messages</tt> which can
answer most of the questions above. Obviously if the drives fail you might not
be able to get  the log saved to disk but you can at least scroll back up the
screen using the <tt/SHIFT/ and <tt/PAGE UP/ keys. It may also be useful to
include part of this in your request for help but do not go overboard, keep
it <em/brief/ as a complete log file dumped to Usenet News is more than a
little annoying.
-->
ブート時のテキストが <tt>/var/log/messages</tt> にあること、
ここには上記に関する答えのほとんどがあることも覚えておきましょう。
ドライブに問題がある場合は、
そもそもログをセーブするディスクが無いことになりますが、
でも <tt/SHIFT/ と <tt/PAGE UP/ キーを使えば、
最低限ながらスクリーンをスクロールバックすることもできます。
これらのログの一部分を、質問メッセージに入れてもいいでしょう。
でもあまり入れすぎず、<em/簡潔/にしておきましょう。
ログファイルがUsenet ニュースにダンプされるのは、
「ちょっとイヤだな」というレベルを少々越えていますから。


<!--O
<sect>Concluding Remarks
-->
<sect>終わりに
<p>
<nidx>disk!conclusion</nidx>
<!--O
Disk tuning and partition decisions are difficult to make, and there are no
hard rules here. Nevertheless it is a good idea to work more on this as the
payoffs can be considerable. Maximizing usage on one drive only while the
others are idle is unlikely to be optimal, watch the drive light, they are
not there just for decoration. For a properly set up system the lights should
look like Christmas in a disco. Linux offers software RAID but also support
for some hardware base SCSI RAID controllers. Check what is available. As
your system and experiences evolve you are likely to repartition and you
might look on this document again. Additions are always welcome.
-->
ディスクの調整やパーティション分けの判断は難しい問題です。
原則と言えるものはないのが現状です。
しかしこの問題に取組むことはきっと目に見える利益を生んでくれるでしょう。
あるドライブが酷使されているのに他のドライブは働いていない、
というような状態は最適な状況ではないでしょう。
ドライブのランプを良く見ましょう、ただの飾りで付いてるのではないんですから。
正しくセットアップされたシステムでは、
これらのランプはクリスマスのディスコのように光るでしょう。
Linux ではソフトウェア RAID が使えますし、
サポートされている SCSI RAID コントローラのハードウェアもあります。
何が使えるかを調べましょう。
システムが大きくなり、あなたの経験が豊富になると、
パーティションを変更したくなってくるでしょう。
その時にはまたこの文書を見てください。追加情報は常に歓迎しています。

<!--O
Finally I'd like to sum up my recommendations:
<itemize>
<item>Disks are cheap but the data they contain could be much more
valuable, use and test your backup system.
<item>Work is also expensive, make sure you get large enough disks
as refitting new or repartitioning old disks takes time.
<item>Think reliability, replace old disks before they fail.
<item>Keep a paper copy of your setup, having it all on disk when
the machine is down will not help you much.
<item>Start out with a simple design with a minimum of fancy technology
and rather fit it in later. In general adding is easier than replacing,
be it disks, technology or other features.
</itemize>
-->
最後に私のお勧めをここにまとめておきます。
<itemize>
<item>ディスクは安価ですが、
そこに含まれるデータはずっとずっと価値があります。
システムのバックアップをしましょう。バックアップのテストもしましょう。
<item>作業もまた高価なものです。新しいディスクを追加したり
古いディスクを再パーティションするのは時間のかかる作業ですから、
充分大きなディスクを買っておきましょう。
<item>信頼性について考慮し、古いディスクは故障する前に交換しましょう。
<item>設定を紙にコピーしておきましょう。
すべてをディスク上にいておいたのでは、
マシンがダウンしたらあまり助けにはなりません。
<item>簡単な設計からはじめましょう。特殊な技術は最初はあまり用いず、
のちのち追加していくようにしましょう。一般に追加は置換よりも簡単ですが、
これはディスクや技術などにもあてはまります。
</itemize>

<!--O
<sect1>Coming Soon
-->
<sect1>今後の予定
<p>
<nidx>disk!coming soon</nidx>
<!--O
There are a few more important things that are about to appear here. In
particular I will add more example tables as I am about to set
up two fairly large and general systems, one at work and one at home. These
should give some general feeling on how a system can be set up for either
of these two purposes. Examples of smooth running existing systems are
also welcome.
-->
この文書にはいくつか重要な内容を追加する必要があります。
特に、付録には例をいくつか追加するつもりです。
私は現在 2 つのマシンを立ち上げているところです。
職場で巨大なシステム、そして自宅にごく一般的なシステムです。
この二つの例を挙げれば、どのようにシステムをセットアップするかについて
だいたいの感じをつかんでもらえるものと期待しています。
うまく働いているシステムの例がありましたら、
もちろん送っていただけると大歓迎です。

<!--O
There is also a fair bit of work left to do on the various kinds of file
systems and utilities.
-->
様々なファイルシステムやユーティリティに関しても、
書かなければならないことがたくさん残っています。

<!--O
There will be a big addition on drive technologies coming soon
as well as a more in depth description on using
<tt>fdisk</tt>, <tt>cfdisk</tt> and <tt>sfdisk</tt>.
The file systems will be beefed up as more features become available
as well as more on RAID and what directories can benefit from what
RAID level.
-->
ドライブの技術に関して、
また <tt/fdisk/ や <tt/cfdisk/, <tt/sfdisk/ の具体的な使い方に関して、
かなりの分量を追加するつもりです。
利用可能になるであろうファイルシステムに関して、
また RAID に関して、 RAID のそれぞれのレベルが
具体的にどのようなディレクトリに有益であるかに関しても増強するつもりです。

<!--
Also I hope to get some information from DPT who make the only RAID
controller supported by Linux so far. I have contacted them but have
yet to hear from them.
Recently I received an information pack from DPT, who made the first
hardware RAID supported by Linux. Their leaflets now carry the familiar
penguin logo to show they support Linux. More in-depth information will
come soon. -->

<!--O
There is some minor overlapping with
the Linux Filesystem Structure Standard and FHS
that I hope to integrate better soon, which will
probably mean a big reworking
of all the tables at the end of this document.
-->
Linux Filesystem Structure Standard や FHS と重複している
ところが少々ありますので、できればより良い形でまとめ直したいと思っています。
付録の表は全面的に書き直す必要があるでしょう。

<!--O
As more people start reading this I should get some more
comments and feedback. I am also thinking of making a program
that can automate a fair bit of this decision making process
and although it is unlikely to be optimum it should provide
a simpler, more complete starting point.
-->
多くの人々がこの文書を読むにつれ、
コメントやフィードバックも多数寄せられることと思います。
現在私は、この文書で述べたディレクトリ配置の決定プロセスを
自動化するようなプログラムができないかと考えています。
最適な配置を吐き出すのはなかなか難しいでしょうが、
スタートポイントとしてふさわしい簡潔な結果を出せるようになると良いと思います。

<!--O
<sect1>Request for Information
-->
<sect1>情報募集
<p>
<nidx>disk!request for information</nidx>
<!--O
It has taken a fair bit of time to write this document and although
most pieces are beginning to come together there are still some
information needed before we are out of the beta stage.
-->
この文書を書きはじめてから随分経ち、多くの部分が統合されつつありますが、
まだこの文書をベータからリリース版にするには以下のような情報が必要です。

<itemize>
<!--O
<item> More information on swap sizing policies is needed as well as
information on the largest swap size possible under the various kernel
versions.
-->
<item>スワップサイズの決定法に関するより多くの情報、
またそれぞれのカーネルのバージョンで利用できる
最大のスワップサイズに関する情報。

<!--O
<item> How common is drive or file system corruption? So far I have
only heard of problems caused by flaky hardware.
-->
<item>ドライブやファイルシステムは、どの程度の頻度で壊れるものなのか。

<!--O
<item> References to speed and drives is needed.
-->
<item>ドライブの速度に関する基準。

<!--O
<item> Are any other Linux compatible RAID controllers available?
-->
<item>Linux で利用可能な他の RAID コントローラの情報。

<!-- <item> Leads to file system, volume management and other related
software is welcome. -->

<!--O
<item> What relevant monitoring, management and maintenance
tools are available?
-->
<item>ディスクの監視・管理・メンテナンスに良いツールがあるか？

<!--O
<item> General references to information sources are needed, perhaps
this should be a separate document?
-->
<item>情報源に関する一般的な参考情報。別の文書にするべきか？

<!--O
<item> Usage of <tt>/tmp</tt> and <tt>/var/tmp</tt> has been hard to
determine, in fact what programs use which directory is not well defined
and more information here is required. Still, it seems at least clear
that these should reside on different physical drives in order to increase
paralellicity.
-->
<item><tt>/tmp</tt> と <tt>/var/tmp</tt> の利用法を決定するのは
今のところ難しく、
どのプログラムがこれらのディレクトリを利用しているのかもよく分かっていません。
情報がありましたら知らせてください。
しかし、少なくともこれらを別の物理ドライブに置いて、
並列性を高めるべきであることは明らかなようです。
</itemize>

<!--O
<sect1>Suggested Project Work
-->
<sect1>著者が提案するプロジェクト
<p>
<nidx>disk!projects, suggested</nidx>
<!--O
Now and then people post on comp.os.linux.*, looking for good project
ideas. Here I will list a few that comes to mind that are relevant to
this document. Plans about big projects such as new file systems should
still be posted in order to either find co-workers or see if someone is
already working on it.
-->
comp.os.linux.* ニュースグループには
「何かプロジェクトをやりたいんだけど、良いアイディアはないですか」
という投稿が時々寄せられます。
ここでは、この文書を書いているうちに私が思い付いたものをいくつか記します。
ファイルシステムのような大きなプロジェクトでは、
共同作業者を探したり手を着けている人がいないかを
調べたりする必要がありますから、ニュースへのポストが必要かもしれません。

<descrip>

<!--O
<tag/Planning tools/ that can automate the design process outlines
earlier would probably make a medium sized project, perhaps as an
exercise in constraint based programming.
-->
<tag/設計ツール/
先に述べたような、パーティション分割の作業を自動化するようなツールは
中規模のプロジェクトになるでしょう。
制限付き問題を解決するプログラムの練習になるでしょう。

<!--O
<tag/Partitioning tools/ that take the output of the previously
mentioned program and format drives in parallel and apply the
appropriate symbolic links to the directory structure. It would
probably be best if this were integrated in existing system
installation software. The drive partitioning setup used in
Solaris is an example of what it can look like.
-->
<tag/パーティション分割ツール/
設計ツールの出力を受け、ドライブをフォーマットし、
ディレクトリ構造に適宜必要なシンボリックリンクをあてがってくれるものです。
システムのインストールソフトと統合されるとベストでしょう。
Solaris についているパーティション分割ツールが良いお手本になるでしょう。

<!--O
<tag/Surveillance tools/ that keep an eye on the partition sizes
and warn before a partition overflows.
-->
<tag/監視ツール/
パーティションのサイズを監視し、あふれる前に警告してくれるツールです。

<!--O
<tag/Migration tools/ that safely lets you move old structures to
new (for instance RAID) systems. This could probably be done as a
shell script controlling a back up program and would be rather
simple. Still, be sure it is safe and that the changes can be undone.
-->
<tag/移動ツール/
安全にディレクトリ構造を古いドライブから新しいドライブ
(例えば RAID など) へ移動してくれるものです。
多分簡単で、バックアップ用のプログラムをコントロールする
シェルスクリプトでも実現できるかもしれません。
しかし安全であるかどうか、
移動後に変更がないかどうかはしっかりチェックされなければなりません。

</descrip>

<!--O
<sect>Questions and Answers
-->
<sect>Q &amp; A
<p>
<nidx>disk!FAQ</nidx>
<nidx>disk!frequently asked questions</nidx>
<!--O
This is just a collection of what I believe are the most common
questions people might have. Give me more feedback and I will
turn this section into a proper FAQ.
-->
よくありそうな質問であると筆者が判断したものを集めました。
読者からのフィードバックを期待します。
そうすれば、この節はちゃんとした FAQ にできるでしょう。

<itemize>

<!--O
<item>Q:How many physical disk drives (spindles) does a Linux system need?
<p>
A: Linux can run just fine on one drive (spindle).  Having enough 
RAM (around 32 MB, and up to 64 MB) to support swapping is a 
better price/performance choice than getting a second disk.
(E)IDE disk is usually cheaper (but a little slower) than SCSI.
-->
<item>Q: Linux に必要な物理ディスクドライブは何台でしょう？
<p>
A: Linux は一台のドライブでもちゃんと動作します。
スワッピングを避けるためには、
2 台目のディスクを買うよりも充分な RAM  (32〜64 MB 程度)
を用意する方がコストパフォーマンスとしては良いでしょう。
ディスクとしては
(E)IDE の方が SCSI よりも安いようです (ただし多少遅いです)。

<!--O
<item>Q: I have a single drive, will this HOWTO help me?
<p>
A: Yes, although only to a minor degree. Still, section
<ref id="physical-track-positioning" name="Physical Track Positioning">
will offer you some gains.
-->
<item>Q: 私はドライブを一台しか使っていないんですが、
この HOWTO は役に立ちますか？
<p>
A: はい。しかし度合いは少々低くなるかもしれません。それでも
<ref id="physical-track-positioning" name="トラックの配置">
の節はきっと有益でしょう。

<!--O
<item>Q: Are there any disadvantages in this scheme?
<p>
A: There is only a minor snag: if even a single partition overflows
the system might stop working properly. The severity depends of course
on what partition is affected. Still this is not hard to monitor, the
command <tt/df/ gives you a good overview of the situation. Also check
the swap partition(s) using <tt/free/ to make sure you are not about
to run out of virtual memory.
-->
<item>Q: この HOWTO の手法の欠点は？
<p>
A: 一つあります。どれかのパーティションがあふれると、
システムがちゃんと動作しなくなってしまいます。
どの程度深刻な問題になるかはもちろんあふれたパーティションに依存します。
しかしパーティションがあふれないように監視することはそれほど難しくなく、
<tt/df/ を実行すれば現状の概要はわかります。
またスワップのパーティションも <tt/free/ でチェックして、
仮想メモリ領域を使い切らないように注意しましょう。

<!--O
<item>Q: OK, so should I split the system into as many partitions
as possible for a single drive?
<p>
A: No, there are several disadvantages to that. First of all maintenance
becomes needlessly complex and you gain very little in this. In fact if your
partitions are too big you will seek across larger areas than needed.
This is a balance and dependent on the number of physical drives you have.
-->
<item>Q: なるほど、では私はそれぞれのドライブを
できるだけ多くのパーティションに区切るべきなんですね？
<p>
いいえ。あまり多すぎても問題が生じます。
まず管理が必要以上に複雑になってしまいます。
一方パーティションが大きすぎると、
これまた必要以上にシーク動作が長くかかってしまうことになります。
これらのバランスをよく考えて決めてください。
使っているドライブの台数にもよるでしょう。

<!--O
<item>Q: Does that mean more drives allows more partitions?
<p>
A: To some degree, yes. Still, some directories should not be split
off from root, check out the file system standards for more details.
-->
<item>Q: ということはドライブが多くなると
パーティションも多くするべきなのですか？
<p>
A: ある意味ではそうです。
しかしルートから分割すべきではないディレクトリがあることに注意してください。
詳細はファイルシステムに関する標準化文書を参考にしてください。

<!--O
<item>Q: What if I have many drives I want to use?
<p>
A: If you have more than 3-4 drives you should consider using RAID of
some form. Still, it is a good idea to keep your root partition on a
simple partition without RAID, see section
<ref id="RAID" name="RAID"> for more details.
-->
<item>Q: ドライブを多数利用したいときにはどうすべきでしょう？
<p>
A: 3〜4 台以上のドライブを使う場合は RAID を考慮すべきだと思います。
しかしその場合もルートパーティションは
RAID でないパーティションに置いておく方がよいでしょう。詳しくは
<ref id="RAID" name="RAID">
の章を参考にしてください。

<!--O
<item>Q: I have installed the latest Windows95 but cannot access this
partition from within the Linux system, what is wrong?
<p>
A: Most likely you are using <tt/FAT32/ in your windows partition. It
seems that Microsoft decided we needed yet another format, and this
was introduced in their latest version of Windows95, called OSR2.
The advantage is that this format is better suited to large drives.

You might also be interested to hear that Microsoft NT 4.0 does not
support it yet either.
-->
<item>Q: 最新版の Windows95 を入れたパーティションが
Linux から見えません。何が悪いんでしょう？
<p>
A: そのパーティションが <tt/FAT32/ になっている可能性が一番高いと思います。
これは Microsoft が最新版の Windows95 (OSR2) に導入したファイルシステムです。
<tt/FAT32/ の利点は大きなドライブの利用に向いていることです。

Microsoft NT 4.0 でもまだサポートされていないファイルシステムだ、
と言うことも知っておいて良いかもしれません。

<!--O
<item>Q: I cannot get the disk size and partition sizes to match,
something is missing. What has happened?
<p>
A:It is possible you have mounted a partition onto a mount point that
was not an empty directory. Mount points are directories and if it
is not empty the mounting will mask the contents. If you do the sums
you will see the amount of disk space used in this directory is
missing from the observed total.

To solve this you can boot from a rescue disk and see what is hiding
behind your mount points and remove or transfer the contents by
mounting the offending partition on a temporary mounting point. You
might find it useful to have "spare" emergency mounting points ready
made.
-->
<item>Q: ディスク容量と各パーティションの容量が合いません。
足りない分はどこに行っちゃったんでしょう？
<p>
A: マウントポイントのディレクトリが空でなかった可能性があります。
この場合、マウント前の内容は隠されてしまい、
このディレクトリの容量分がディスクから
消えてしまったように見えることがあります。

この場合はレスキューディスクなどを使ってブートし、
マウントポイントに隠れてしまっているファイルを消去するか、
あるいは一時領域に非難させて下さい。
緊急用にマウントポイントのスペアを作っておくと便利かもしれません。

<!--O
<item>Q: It doesn't look like my swap partition is in use, how come?
<p>
A: It is possible that it has not been necessary to swap out,
especially if you have plenty of RAM. Check your log files to see
if you ran out of memory at one point or another, in that case
your swap space should have been put to use. If not it is
possible that either the swap partition was not assigned the
right number, that you did not prepare it with <tt/mkswap/ or
that you have not done <tt/swapon/ or added it to your
<!-\- <file/fstab/. -\->
<htmlurl url="file:///etc/fstab"
    name="/etc/fstab">
file.
-->
<item>Q: 私のスワップパーティションは使われてないみたいなんですが、
どうしてでしょう？
<p>
A: スワップアウトの必要がなかったのかもしれません。
特に RAM が充分ある場合は、その可能性が高いですね。
ログファイルをチェックして、
ある瞬間にメモリを使い切った旨の記録があるか調べてください。
記録があれば、スワップパーティションは置いておく必要があったのです。
記録がなければ、
スワップパーティションが正しい番号に割り当てられていなかったり、
<tt/mkswap/ していなかったり、
<tt/swapon/ していなかったり
<htmlurl url="file:///etc/fstab"
    name="/etc/fstab">
ファイルへ追加していないのかもしれません。


<!--O
<item>Q: What is this Nyx that is mentioned several times here?
<p>
A: It is a large free Unix system with currently about 10000 users.
I use it for my web pages for this HOWTO as well as a source
of ideas for a setup of large Unix systems. It has been running for
many years and has a quite stable setup. For more information you can
view the 
<url url="http://www.nyx.net"
    name="Nyx homepage">
which also gives you information on how to get your own free account.
-->
<item>Q: 何回か Nyx って言葉が出てきますけど、これはなんですか？
<p>
A: 誰でも自由に使うことのできる大きな Unix システムで、
現在 10000 人ほどのユーザがいます。
私はこの HOWTO の web ページを nyx に置いています。
また大きな Unix システムの設定に関するアイディアの源でもあります。
長いこと非常に安定して動作しています。詳しい情報は
<url url="http://www.nyx.net" name="Nyx Homepage">
をご覧ください。無料アカウントの取得方法についても記述があります。
</itemize>


<!--O
<sect>Bits and Pieces <label id="bits-n-pieces">
-->
<sect>補遺<label id="bits-n-pieces">
<p>
<nidx>disk!miscellaneous</nidx>
<!--O
This is basically a section where I stuff all the bits I have not yet
decided where should go, yet that I feel is worth knowing about. It is
a kind of transient area.
-->
この章は未分類の情報を集めたものです。
それぞれの情報はそれなりに面白いと思います。
一時的な領域だと思ってください。

<!-- removed 990124
<sect1>Combining <tt/swap/ and <tt>/tmp</tt> <label id="comb-swap-n-tmp">
<p>
<nidx>disk!miscellaneous!swap and tmp combined</nidx>
Recently there have been discussions in the various Linux related
news groups about specialized file systems for temporary storage.
This is partly inspired by the <tt/tmpfs/ on *BSD* and Solaris, as
well as <tt/swapfs/ on the NeXT machines.

The rationale is that these are temporary storage that normally
does not require much space, yet in normal systems you need to
reserve a certain amount of space for these. Elementary statistical
knowledge tells you (very simplified) that when you sum a number of
variables the relative statistical uncertainty decreases. So combining
<tt/swap/ and <tt>/tmp</tt> you do not need to reserve as much space
as you otherwise would need.

This specialized file system is nothing more than a swappable RAM disk
that are swapped out to disk when and only when space is limited, thus
effectively putting temporary files on the swap partition.

There is, however, a snag. This scheme prevents you from getting
parallel activity on <tt/swap/ and <tt>/tmp</tt> drives so under
heavy activity the system takes a bigger performance hit. Put
another way, you trade speed to get space. Interleaving across
multiple drives reduces this somewhat.

Also there is the security problem with users bringing down the
machine by overflowing the <tt>/tmp</tt> directory.
 -->

<!-- redundant
<sect1>Interleaved <tt/swap/ drives.
<p>
<nidx>disk!miscellaneous!interleaved swap drives</nidx>
This is not striping across several drives, instead drives are accessed
in a round robin fashion in order to spread the load in a crude fashion.
In Linux you additionally have a priority parameter you can adjust for
tuning your system, especially useful if your disks differs  significantly
in speed. Check <tt/man 8 swapon/ as well as <tt/man 2 swapon/ for more
information. -->

<!--O
<sect1>Swap Partition: to Use or Not to Use
-->
<sect1>スワップパーティション: 使うべきか使わざるべきか？
<p>
<nidx>disk!miscellaneous!swap or no swap</nidx>
<!--O
In many cases you do not need a swap partition, for instance if you
have plenty of RAM, say, more than 64 MB, and you are the sole user
of the machine. In this case you can experiment running without a
swap partition and check the system logs to see if you ran out of
virtual memory at any point.
-->
スワップパーティションを必要としない場合も少なくありません。
例えば RAM が充分にあり (64 MB くらいでしょうか)、
またユーザが一人しかいないような場合です。
このような場合は実験的にスワップパーティション無しでシステムを運用し、
仮想メモリを使い切っていないかをシステムのログで確認してみても良いでしょう。

<!--O
Removing swap partitions have two advantages:
<itemize>
<item>you save disk space (rather obvious really)
<item>you save seek time as swap partitions otherwise would
lie in the middle of your disk space.
</itemize>
-->
スワップパーティションを使わない選択には以下のような利点があります。
<itemize>
<item>(あたりまえですが) ディスクスペースの節約になります。
<item>スワップパーティションはシークに有利なディスクの真ん中に置かれる
ことが多いので、スワップを省略すれば代わりに高速アクセスが必要とされる
パーティションを置くことができます。
</itemize>

<!--O
In the end, having a swap partition is like having a heated toilet:
you do not use it very often, but you sure appreciate it when
you require it.
-->
簡単に言えば、スワップパーティションは便座の暖房機能みたいなものです。
そんなに頻繁に使うものではないですが、
必要な時にはその存在は非常にありがたいものです。

<!--O
<sect1>Mount Point and <tt>/mnt</tt>
-->
<sect1>マウントポイントと <tt>/mnt</tt>
<p>
<nidx>disk!miscellaneous!mount point issues</nidx>
<!--O
In an earlier version of this document I proposed to put all
permanently mounted partitions under <tt>/mnt</tt>. That, however, is
not such a good idea as this itself can be used as a mount point, which
leads to all mounted partitions becoming unavailable. Instead I will
propose mounting straight from root using a meaningful name like
<tt>/mnt.descriptive-name</tt>.
-->
この文書の以前の版では、各種のマウントポイントを
<tt>/mnt</tt> 以下のサブディレクトリにしていました。
しかしこれは良い考えではありませんでした。
なぜなら <tt>/mnt</tt> 自身がマウントポイントとして使われると、
それ以下のディレクトリがアクセス不可能になってしまうからです。
この版からは、代わりにマウントポイントをルートファイルシステム直下に 
<tt>/mnt.descriptive-name</tt> と言うかたちで記述するようにしました。

<!--O
Lately I have become aware that some Linux distributions use mount points
at subdirectories <em/under/ <tt>/mnt</tt>, such as <tt>/mnt/floppy</tt>
and <tt>/mnt/cdrom</tt>, which just shows how confused the whole issue is.
Hopefully FHS should clarify this.
-->
最近気づいたのですが、
Linux の配布パッケージによってはマウントポイントを
<tt>/mnt</tt> 以下のサブディレクトリ
(<tt>/mnt/floppy</tt> とか <tt>/mnt/cdrom</tt> など！)
にしているものもあるようです。
状況の混乱を示す一例といえます。 FHS によって解決するとよいのですが。

<!-- 
<sect1>SCSI Id Numbers and Names
<p>
<nidx>disk!miscellaneous!SCSI id numbers vs. names</nidx>
Partitions are labeled in the order they are found, <em/not/ depending
on the SCSI id number. This means that if you add a drive with an id
number inserted in the previous order of numbers, or change id number
in any other way, the partition names will be messed up. This is
important if you use removable media. In order to save yourself from some
unpleasant experiences, you are recommended to use low numbers for fixed
media and reserve the last number(s) for removable media drives.

Many have been bitten by this misfeature and there is a strong call for
something to be done about it. Nobody knows how soon this will be fixed
so in the meantime it is wise to take this into consideration when you
design your system. For instance it may be a good idea to use the lowest
SCSI id number for your root disk so that it has the least probability of
being renumbered should one drive fail.

The source of the problem lies in the limited number of bits available
for major and minor numbering in the device files used to describe the
device itself. You can see these in the <tt>/dev</tt> directory, info
on the numbering and allocation can be found in <tt/man MAKEDEV/.
Currently there are 2 solutions to this problem in various stages of
development:
<descrip>
<tag/scsidev/ works by creating a database of drives and where they
belong, check <tt/man scsifs/ for more information
<tag/devfs/ is a more long term project aimed at getting around the
whole business of device numbering by making the <tt>/dev</tt>
directory a kernel file system in the same way as <tt>/procfs</tt>
is.
More information will appear as it becomes available.
</descrip>

SCSI numbers are also used for arbitration. If several drives request
service, the drive with the lowest number is given priority.
 -->

<!--O
<sect1>Power and Heating  <label id="power-heating">
-->
<sect1>電力と発熱<label id="power-heating">
<p>
<nidx>disk!miscellaneous!power-related issues</nidx>
<nidx>disk!miscellaneous!heat-related issues</nidx>
<!--O
Not many years ago a machine with the equivalent power of a modern PC
required 3-phase power and cooling, usually by air conditioning the machine
room, some times also by water cooling. Technology has progressed very
quickly giving not only high speed but also low power components. Still,
there is a definite limit to the technology, something one should keep in
mind as the system is expanded with yet another disk drive or PCI
card. When the power supply is running at full rated power, keep in mind
that all this energy is going somewhere, mostly into heat. Unless this is
dissipated using fans you will get a serious heating inside the cabinet
followed by a reduced reliability and also life time of the electronics.
Manufacturers state minimum cooling requirements for their drives, usually
in terms of cubic feet per minute (CFM). You are well advised to take this
serious.
-->
現代の PC と同じような性能の計算機が三相電源と専用の冷却
(大抵は空冷とマシンルームの空調でしたが、水冷のものもありました)
を必要としていた時代はそんなに古いことではありません。
技術の急速な進歩は、高速化だけでなく部品の低電力化をももたらしました。
しかしそれでも限界というものはあります。
ディスクや PCI カードを追加することによってシステムが大きくなるごとに、
電力のことを考えておく必要があります。
電源が供給する電力は、そのほとんどが熱になります。
もしこの熱がファンによって逃げなければ、ケース内部は相当な温度になり、
電子パーツの性能や寿命の低下の原因になります。
メーカは冷却に関する推奨値を挙げているはずで、
通常は立方フィート毎分 (CFM) 単位の数値です。
この数値は真面目に考えておく方が良いと思います。

<!--O
Keep air flow passages open, clean out dust and check the temperature of your
system running. If it is too hot to touch it is probably running too hot.
-->
空気の通り道を確保し、ほこりを払って、
システムが動作中の温度を測ってみましょう。
触れないくらい熱くなっていたら、それは少々問題です。

<!--O
If possible use sequential spin up for the drives. It is during
spin up, when the drive platters accelerate up to normal speed,
that a drive consumes maximum power and if all drives start up
simultaneously you could go beyond the rated power maximum of
your power supply.
-->
可能ならドライブにシーケンシャルスピンアップを用いるようにしましょう。
ドライブは円板の回転加速に最大の電力を必要とするので、
すべてのドライブを同時にスタートさせると
電源の電力許容値を越えてしまう可能性があります。

<sect1>Deja
<p>
<nidx>disk!miscellaneous!Dejanews</nidx>
<nidx>disk!miscellaneous!Deja</nidx>
<nidx>disk!reliability</nidx>
<!--O
This is an Internet system that no doubt most of you are familiar with.
It searches and serves <em/Usenet News/ articles from 1995 and to the
latest postings and also offers a web based reading and posting interface.
There is a lot more, check out
<url url="http://www.deja.com"
    name="Deja">
for more information. It changed name from Dejanews.
-->
これはインターネットのサイトで、
おそらく読者の多くがすでに利用していることでしょう。
ここでは 1995 年から最新のポストに至るまでの
Usenet ニュースの記事を検索・閲覧できます。
また WWW を通してニュースの購読やポストを行うこともできます。
他にも色々な機能があります。
<url url="http://www.deja.com"
    name="Deja">
に行ってみてください。 Dejanews から名前が変わりました。

<!--O
What perhaps is less known, is that they use about 120 Linux SMP
computers many of which use the <tt/md/ module to manage between 4
and 24 Gig of disk space (over 1200 Gig altogether) for this service.  
The system is continuously growing but at the time of writing they 
use mostly dual Pentium Pro 200MHz and Pentium II 300 MHz
systems with 256 MB RAM or more.
-->
こちらはあまり知られていないでしょうが、
このサイトは Linux で動作している、
およそ 120 台の SMP コンピュータで運用されています。
それぞれは md モジュールを用いて 4〜24 GB のディスクを利用しています
(全体で 1200 GB 以上)。システムは大きくなり続けていますが、
本文書の執筆現在では、
それぞれが dual Pentium Pro 200 MHz または Peintium II 300 MHz のシステムで、
256 MB 以上の RAM を積んでいます。

<!--O
A production database machine normally has 1 disk for the operating system and
between 4 and 6 disks managed by the <tt/md/ module where the articles are
archived.
The drives are connected to BusLogic Model BT-946C and BT-958
PCI SCSI adapters, usually one to a machine.
-->
データベースを生成するマシンは一台のディスクを OS 用に利用し、
4〜6 台のディスクを md モジュールで管理して、
記事のアーカイブに当てています。ドライブは BusLogic の 
BT-946C PCI SCSI アダプタに接続されています (だいたい一台につき二枚)。

<!-- Added 980809, to be checked -->
<!--O
For the production
systems (which are up 365 days a year) the downtime attributable to
disk errors is less than 0.25 % (that is a quarter of 1%, not 25%).
-->
生成システム (年 365 日可動します) での、ディスクエラーによる
ダウンタイムは 0.25 &percnt; 以下だそうです (25&percnt じゃないですよ!)。
<!-- end of addition -->

<!--O
Just in case: this is not an advertisement, it is stated as an
example of how much is required for what is a major Internet
service.
-->
これは事例紹介であって、宣伝しているわけではありません。
メジャーなインターネットサービスにどの程度のハードウェアが必要になるのか、
例として挙げているだけです。

<!-- removed 221198
<sect1>File System Structure
<p>
<nidx>disk!miscellaneous!filesystem structure</nidx>
There are many file system structures in existence, differing with
FSSTND (and soon FHS) to varying degree both in terms of philosophy,
strategy and implementation. It is not possible to detail all here,
instead the interested reader should read the relevant manual page,
<tt/man hier/ which is available on many platforms and implementations.
 -->

<!-- removed 221198
<sect1>Track Numbering and Optimizing Schemes
<p>
<nidx>disk!miscellaneous!track numbering</nidx>
<nidx>disk!miscellaneous!optimization</nidx>
In the old days the file system used to take advantage of knowing the
physical drive parameters in order to optimize transfers, for instance
by endeavouring to keep a file within a single track if possible which
saves track-to-track seek time. These days with logical drive parameters,
drive cache and schemes to map out bad sectors, such optimizations
become meaningless and might even cost more than it would gain. As most
Linux installations use modern file systems these schemes are not used,
however, some other operating systems have retained such schemes.
 -->

<!--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 -->


<!--O
<sect>Appendix A: Partitioning Layout Table: Mounting and Linking <label id="app-a">
-->
<sect>付録 A: パーティション配置表: マウントとリンク<label id="app-a">
<p>
<nidx>disk!partitioning layout table!mounting and linking</nidx>
<!--O
The following table is designed to make layout a simpler paper
and pencil exercise. It is probably best to print it out (using
NON PROPORTIONAL fonts) and adjust the numbers until you are
happy with them.
-->
以下に示した表は、パーティション配置を
紙とエンピツで簡単に行えるようにしたものです。
プリントアウトして (プロポーショナルフォントは使わないように！)
満足行くまで番号合わせを行なうのが良いでしょう。

<!--O
Mount point is what directory you wish to mount a partition on or
the actual device. This is also a good place to note how you plan
to use symbolic links.
-->
マウントポイント (Mount point) は、
実際のパーティションまたはデバイスをマウントするディレクトリです。
ここにはシンボリックリンクとするかどうかも書いておくと良いでしょう。

<!--O
The size given corresponds to a fairly big Debian 1.2.6 installation.
Other examples are coming later.
-->
ここにある容量は Debian 1.2.6
で比較的たくさんの物をインストールした場合に対応しています。
他の例もそのうち追加するつもりです。

<!--O
Mainly you use this table to select what structure and drives you will use,
the partition numbers and letters will come from the next two tables.
-->
この表はどんなディレクトリ構造やドライブを使うかを決めるのに用いると
良いでしょう。実際のパーティション番号は、続く 2 つの表で決めます。

<tscreen><verb>
Directory	Mount point	speed	seek	transfer	size	SIZE


swap		__________	ooooo	ooooo	ooooo		32	____

/		__________	o	o	o		20	____

/tmp		__________	oooo	oooo	oooo			____

/var		__________	oo	oo	oo		25	____
/var/tmp	__________	oooo	oooo	oooo			____
/var/spool	__________						____
/var/spool/mail	__________	o	o	o			____
/var/spool/news	__________	ooo	ooo	oo			____
/var/spool/____	__________	____	____	____			____

/home		__________	oo	oo	oo			____

/usr		__________					500	____
/usr/bin	__________	o	oo	o		250	____
/usr/lib	__________	oo	oo	ooo		200	____
/usr/local	__________						____
/usr/local/bin	__________	o	oo	o			____
/usr/local/lib	__________	oo	oo	ooo			____
/usr/local/____	__________						____
/usr/src	__________	o	oo	o		50	____

DOS		__________	o	o	o			____
Win		__________	oo	oo	oo			____
NT		__________	ooo	ooo	ooo			____

/mnt._________	__________	____	____	____			____
/mnt._________	__________	____	____	____			____
/mnt._________	__________	____	____	____			____
/_____________	__________	____	____	____			____
/_____________	__________	____	____	____			____
/_____________	__________	____	____	____			____



Total capacity:
</verb></tscreen>

<!--O
<sect>Appendix B: Partitioning Layout Table: Numbering and Sizing <label id="app-b">
-->
<sect>付録 B: パーティション配置表: 番号付けと容量の割り振り<label id="app-b">
<p>
<nidx>disk!partitioning layout table!numbering and sizing</nidx>
<!--O
This table follows the same logical structure as the table above
where you decided what disk to use. Here you select the physical
tracking, keeping in mind the effect of track positioning mentioned
earlier in
<ref id="physical-track-positioning" name="Physical Track Positioning">.
-->
この表は上の表と同じディレクトリ構造が並んでいますが、
どのディスクを使うかを決めるために使います。
ここではディスク上での配置を決めます。
この文書の
<ref id="physical-track-positioning" name="トラックの配置">
の節で紹介した、セクタの位置による効果を心に留めながら行ってください。

<!--O
The final partition number will come out of the table after this.
-->
最終的なパーティションの番号はこの次の表に書きます。

<tscreen><verb>
  Drive		  sda	  sdb	  sdc	  hda	  hdb	  hdc	  ___

SCSI ID		|  __	|  __	|  __	|

Directory
swap		|	|	|	|	|	|	|

/		|	|	|	|	|	|	|

/tmp		|	|	|	|	|	|	|

/var		:	:	:	:	:	:	:
/var/tmp	|	|	|	|	|	|	|
/var/spool	:	:	:	:	:	:	:
/var/spool/mail	|	|	|	|	|	|	|
/var/spool/news	:	:	:	:	:	:	:
/var/spool/____	|	|	|	|	|	|	|

/home		|	|	|	|	|	|	|

/usr		|	|	|	|	|	|	|
/usr/bin	:	:	:	:	:	:	:
/usr/lib	|	|	|	|	|	|	|
/usr/local	:	:	:	:	:	:	:
/usr/local/bin	|	|	|	|	|	|	|
/usr/local/lib	:	:	:	:	:	:	:
/usr/local/____	|	|	|	|	|	|	|
/usr/src	:	:	:	:

DOS		|	|	|	|	|	|	|
Win		:	:	:	:	:	:	:
NT		|	|	|	|	|	|	|

/mnt.___/_____	|	|	|	|	|	|	|
/mnt.___/_____	:	:	:	:	:	:	:
/mnt.___/_____	|	|	|	|	|	|	|
/_____________	:	:	:	:	:	:	:
/_____________	|	|	|	|	|	|	|
/_____________	:	:	:	:	:	:	:


Total capacity:

</verb></tscreen>


<!--O
<sect>Appendix C: Partitioning Layout Table: Partition Placement <label id="app-c">
-->
<sect>付録 C: パーティション配置表: パーティションの作成<label id="app-c">
<p>
<nidx>disk!partitioning layout table!partition placement</nidx>
<!--O
This is just to sort the partition numbers in ascending order ready
to input to fdisk or cfdisk. Here you take physical track positioning
into account when finalizing your design. Unless you get specific
information otherwise, you can assume track 0 is the outermost track.
-->
この表は fdisk や cfdisk の入力に便利なように、
パーティションの番号順に並び替えたものです。
ここで配置を完成させる際、
やはりセクタの配置は考慮に入れておくようにしてください。
特に他に情報がなければ、トラック 0 が最外周と思ってよいでしょう。

<!--O
These numbers and letters
are then used to update the previous tables, all of which you will find
very useful in later maintenance.
-->
この番号とドライブレターは前の 2 つの表を更新するときに使うと良いでしょう。
きっと後々メンテナンスが非常に楽になると思います。

<!--O
In case of disk crash you might find it handy to know what SCSI id
belongs to which drive, consider keeping a paper copy of this.
-->
ディスククラッシュが起こった場合などには、
SCSI ID とドライブの対応が付けにくくなるものです。
これは紙にコピーして保存しておきましょう。

<tscreen><verb>
	Drive :	  sda	  sdb	  sdc	  hda	  hdb	  hdc	  ___

Total capacity:	|  ___	|  ___	|  ___	|  ___	|  ___	|  ___	|  ___
SCSI ID		|  __	|  __	|  __	|

Partition

1		|	|	|	|	|	|	|
2		:	:	:	:	:	:	:
3		|	|	|	|	|	|	|
4		:	:	:	:	:	:	:
5		|	|	|	|	|	|	|
6		:	:	:	:	:	:	:
7		|	|	|	|	|	|	|
8		:	:	:	:	:	:	:
9		|	|	|	|	|	|	|
10		:	:	:	:	:	:	:
11		|	|	|	|	|	|	|
12		:	:	:	:	:	:	:
13		|	|	|	|	|	|	|
14		:	:	:	:	:	:	:
15		|	|	|	|	|	|	|
16		:	:	:	:	:	:	:

</verb></tscreen>


<!--O
<sect>Appendix D: Example: Multipurpose Server
-->
<sect>付録 D: 例 1: 多目的サーバ
<p>
<nidx>disk!example!server, multi-purpose</nidx>
<!--O
The following table is from the setup of a medium sized multipurpose
server where I once worked. Aside from being a general Linux machine it will
also be a network related server (DNS, mail, FTP, news, printers etc.)
X server for various CAD programs, CD ROM burner and many other things.
The files reside on 3 SCSI drives with a capacity of 600, 1000 and 1300
MB.
-->
以下の表は、私がかつての勤務先で中規模の多目的サーバを
セットアップしたときのものです。
通常の Linux マシンとしての機能に加え、ネットワーク関係のサーバ
(DNS、 mail、 ftp、 news、プリントサーバ など) としても働いています。
またいろいろな CAD プログラム用の X サーバや CD-ROM ライタなど、
様々な用途に使っています。
3 台の SCSI ドライブがついていて、容量はそれぞれ 600、1000、1300 MB です。

<!--O
Some further speed could possibly be gained by splitting <tt>/usr/local</tt>
from the rest of the <tt>/usr</tt> system but we deemed the further added
complexity would not be worth it. With another couple of drives
this could be more worthwhile. In this setup drive sda is old and slow
and could just a well be replaced by an IDE drive. The other two drives
are both rather fast. Basically we split most of the load between these
two. To reduce dangers of imbalance in partition sizing we have decided
to keep <tt>/usr/bin</tt> and <tt>/usr/local/bin</tt> in one drive
and <tt>/usr/lib</tt> and <tt>/usr/local/lib</tt> on another separate drive
which also affords us some drive parallelizing.
-->
<tt>/usr/local</tt> を <tt>/usr</tt> から独立させれば
より速度が向上するとは思いますが、
これ以上のシステムの複雑化には見合わないと判断しました。
ドライブが追加されれば考える価値が高まるかもしれません。
sda は古くて遅いドライブで、せいぜい IDE 程度の性能しかありません。
他の 2 台はもっと高速です。
基本的に後者の 2 台に負荷を分割してかけるようにしています。
パーティション容量の偏りが生じないように、 
<tt>/usr/bin</tt> と
<tt>/usr/local/bin</tt> はひとつのドライブに、そして <tt>/usr/lib</tt> 
と <tt>/usr/local/lib</tt> をもうひとつのドライブに配置しました。
これによってドライブ利用の並列化もある程度達成できました。

<!--O
Even more could be gained by using RAID but we felt that as a server we
needed more reliability than was then afforded by the <tt/md/ patch and
a dedicated RAID controller was out of our reach.
-->
RAID を使えばさらにパフォーマンスは向上するでしょうが、
現在利用できる md パッチはサーバに用いるにはまだ信頼性に欠けると判断しました。
本物の RAID コントローラには手が届きませんでした。

<!--O
<sect>Appendix E: Example: Mounting and Linking
-->
<sect>付録 E: 例 1: マウントとリンク
<p>
<nidx>disk!example!mounting and linking</nidx>


<tscreen><verb>
Directory	Mount point	speed	seek	transfer	size	SIZE


swap		sdb2, sdc2	ooooo	ooooo	ooooo		32	2x64

/		sda2    	o	o	o		20	 100

/tmp		sdb3		oooo	oooo	oooo			 300

/var		__________	oo	oo	oo			____
/var/tmp	sdc3		oooo	oooo	oooo			 300
/var/spool	sdb1							 436
/var/spool/mail	__________	o	o	o			____
/var/spool/news	__________	ooo	ooo	oo			____
/var/spool/____	__________	____	____	____			____

/home		sda3		oo	oo	oo			 400

/usr		sdb4						230	 200
/usr/bin	__________	o	oo	o		30	____
/usr/lib	-> libdisk	oo	oo	ooo		70	____
/usr/local	__________						____
/usr/local/bin	__________	o	oo	o			____
/usr/local/lib	-> libdisk	oo	oo	ooo			____
/usr/local/____	__________						____
/usr/src	->/home/usr.src	o	oo	o		10	____

DOS		sda1		o	o	o			 100
Win		__________	oo	oo	oo			____
NT		__________	ooo	ooo	ooo			____

/mnt.libdisk	sdc4		oo	oo	ooo			 226
/mnt.cd		sdc1		o	o	oo			 710


Total capacity: 2900 MB
</verb></tscreen>


<!--O
<sect>Appendix F: Example: Numbering and Sizing
-->
<sect>付録 F: 例 1: 番号付けと容量の割り振り
<p>
<nidx>disk!example!numbering and sizing</nidx>
<!--O
Here we do the adjustment of sizes and positioning.
-->
ここで容量と配置の調整をします。

<tscreen><verb>
Directory	  sda	  sdb	  sdc


swap		|	|   64	|   64	|

/		|  100	|	|	|

/tmp		|	|  300	|	|

/var		:	:	:	:
/var/tmp	|	|	|  300	|
/var/spool	:	:  436	:	:
/var/spool/mail	|	|	|	|
/var/spool/news	:	:	:	:
/var/spool/____	|	|	|	|

/home		|  400	|	|	|

/usr		|	|  200	|	|
/usr/bin	:	:	:	:
/usr/lib	|	|	|	|
/usr/local	:	:	:	:
/usr/local/bin	|	|	|	|
/usr/local/lib	:	:	:	:
/usr/local/____	|	|	|	|
/usr/src	:	:	:	:

DOS		|  100	|	|	|
Win		:	:	:	:
NT		|	|	|	|

/mnt.libdisk	|	|	|  226	|
/mnt.cd		:	:	:  710	:
/mnt.___/_____	|	|	|	|


Total capacity:	|  600	| 1000	| 1300	|

</verb></tscreen>


<!--O
<sect>Appendix G: Example: Partition Placement
-->
<sect>付録 G: 例 1: パーティションの作成
<p>
<nidx>disk!example!partition placement</nidx>
<!--O
This is just to sort the partition numbers in ascending order ready
to input to fdisk or cfdisk. Remember to optimize for physical track
positioning (not done here).
-->
fdisk や cfdisk の入力時に楽なように、
パーティション番号の順番に並び替えたものです。
トラック上の物理的配置に対する最適化を忘れないように
(ここではしていませんが)。

<tscreen><verb>
	Drive :	  sda	  sdb	  sdc

Total capacity:	|   600	|  1000	|  1300	|

Partition

1		|   100	|   436	|   710	|
2		:   100	:    64	:    64	:
3		|   400	|   300	|   300	|
4		:	:   200	:   226	:

</verb></tscreen>

<!--O
<sect>Appendix H: Example II
-->
<sect>付録 H: 例 2
<p>
<nidx>disk!example!server, academic</nidx>

<!--O
The following is an example of a
server setup in an academic setting, and is contributed by
<tt/nakano (at) apm.seikei.ac.jp/. I have only done minor editing to
this section.
-->
以下は <tt/nakano (at) apm.seikei.ac.jp/ より寄せられた大学での利用例です。

<!--O
<tt>/var/spool/delegate</tt> is a directory for storing logs and cache files
of an WWW proxy server program, "delegated". Since I don't notice it
widely, there are 1000-~-1500 requests/day currently, and average
disk usage is 15-~-30% with expiration of caches each day.
-->
<tt>/var/spool/delegate</tt> は WWW のプロキシサーバプログラム
<tt/delegated/ のログやキャッシュのためのディレクトリです。
今のところ使っている人数は少なく、
一日あたり 1000〜1500 アクセスに収まっています。
毎日キャッシュの更新を行っており、
ディスクの利用率は 15〜30 &percnt; 程度です。

<!--O
<tt>/mnt.archive</tt> is used for data files which are big and not frequently
referenced such a s experimental data (especially graphic ones),
various source archives, and Win95 backups (growing very fast...).
-->
<tt>/mnt.archive</tt> は、
巨大かつあまり頻繁には利用されないファイルを置いてあります。
たとえば実験データ (特にグラフィックデータ) や各種のソース、
Win 95 マシンのバックアップなどです。

<!--O
<tt>/mnt.root</tt> is backup root file system containing rescue utilities. A
boot floppy is also prepared to boot with this partition.
-->
<tt>/mnt.root</tt> はルートファイルシステムのバックアップで、
レスキュー用のユーティリティが入っています。
このパーティションから立ち上げるためのブートフロッピーも別に用意してあります。

<tscreen><verb>

=================================================
Directory               sda      sdb     hda    

swap                    |    64 |    64 |       |
/                       |       |       |    20 |
/tmp                    |       |       |   180 |

/var                    :   300 :       :       :
/var/tmp                |       |   300 |       |
/var/spool/delegate     |   300 |       |       |

/home                   |       |       |   850 |
/usr                    |   360 |       |       |
/usr/lib                -> /mnt.lib/usr.lib
/usr/local/lib          -> /mnt.lib/usr.local.lib

/mnt.lib                |       |   350 |       |
/mnt.archive            :       :  1300 :       :
/mnt.root               |       |    20 |       |

Total capacity:            1024    2034    1050


=================================================
        Drive :           sda     sdb     hda
Total capacity:         |  1024 |  2034 |  1050 |

Partition
1                       |   300 |    20 |    20 |
2                       :    64 :  1300 :   180 :
3                       |   300 |    64 |   850 |
4                       :   360 :   ext :       :
5                       |       |   300 |       |
6                       :       :   350 :       :


Filesystem         1024-blocks  Used Available Capacity Mounted on
/dev/hda1              19485   10534     7945     57%   /
/dev/hda2             178598      13   169362      0%   /tmp
/dev/hda3             826640  440814   343138     56%   /home
/dev/sda1             306088   33580   256700     12%   /var
/dev/sda3             297925   47730   234807     17%   /var/spool/delegate
/dev/sda4             363272  170872   173640     50%   /usr
/dev/sdb5             297598       2   282228      0%   /var/tmp
/dev/sdb2            1339248  302564   967520     24%   /mnt.archive
/dev/sdb6             323716   78792   228208     26%   /mnt.lib

</verb></tscreen>

<!--O
Apparently <tt>/tmp</tt> and <tt>/var/tmp</tt> is too big. These
directories shall be
packed together into one partition when disk space shortage comes.
-->
明らかに <tt>/tmp</tt> と <tt>/var/tmp</tt> は大きすぎるようです。
将来ディスクが足りなくなったときには、
これらのディレクトリは一つのパーティションにまとめるべきかもしれません。

<!--O
<tt>/mnt.lib</tt> is also seemed to be, but I plan to install newer TeX and
ghostscript archives, so <tt>/usr/local/lib</tt> may grow about 100 MB or so
(since we must use Japanese fonts!).
-->
<tt>/mnt.lib</tt> もちょっと大きすぎるようですが、
そのうち TeX と ghostscript
の新しいバージョンをインストールするつもりですので、 
<tt>/usr/local/lib</tt> はすぐに 100 MB 程度膨らむのではないかと考えています
(日本語フォント関連が多分巨大なので)。

<!--O
  Whole system is backed up by Seagate Tapestore 8000 (Travan TR-4,
4G/8G). 
-->
システム全体は Seagate TapeStore 8000
(Travan TR-4 4G/8G) でバックアップをとっています。

<!-- 
// 140197 text removed 
It works fine when accessed through <tt>/dev/st0</tt>, but
when done through <tt>/dev/nst0</tt> or with `<tt>mt</tt>' command,
SCSI system get up a panic occasionally. It's not critical, but the
biggest problem rest in our system...
 -->


<!--O
<sect>Appendix I: Example III: SPARC Solaris
-->
<sect>付録 I: 例 3: SPARC Solaris
<p>
<nidx>disk!example!server, industrial</nidx>

<!--O
The following section is the basic design used at work for a number of
Sun SPARC servers running Solaris 2.5.1 in an industrial development
environment. It serves a number of database and cad applications in
addition to the normal services such as mail.
-->
以下は Solaris 2.5.1 を走らせている
Sun SPARC サーバの基本的なデザインの例です。
これらのシステムは実際に仕事で使っており、技術開発の用途に用いています。
通常のメール配送などのジョブに加え、多くのデータベースや
CAD アプリケーションを提供しています。

<!--O
Simplicity is emphasized here so <tt>/usr/lib</tt> has not been split
off from <tt>/usr</tt>.
-->
ここではシンプルであることが重要なので、
<tt>/usr/lib</tt> は <tt>/usr</tt> から分離していません。

<!--O
This is the basic layout, planned for about 100 users.
-->
だいたい 100 人ほどのユーザ向けに作られた基本レイアウトです。

<tscreen><verb>
   Drive:        SCSI 0                      SCSI 1

   Partition     Size (MB)   Mount point    Size (MB)   Mount point

     0           160         swap           160         swap
     1           100         /tmp           100         /var/tmp
     2           400         /usr
     3           100         /
     4            50         /var
     5
     6           remainder   /local0        remainder   /local1

</verb></tscreen>

<!--O
Due to specific requirements at this place it is at times necessary to
have large partitions available on a short notice. Therefore drive 0 is
given as many tasks as feasible, leaving a large <tt>/local1</tt>
partition.
-->
このサーバには特殊な要求があり、たまに大きなパーティションが
(短い間ではありますが) 必要になる場合があります。
そのためドライブ 0 にできるだけ多くの役割を割り当て、
<tt>/local1</tt> に大きなパーティションを残すようにしてあります。

<!--O
This setup has been in use for some time now and found satisfactorily.
-->
この設定で長い間使っていますが、特に不満は生じていません。

<!--O
For a more general and balanced system it would be better to swap <tt>/tmp</tt>
and <tt>/var/tmp</tt> and then move <tt>/var</tt> to drive 1.
-->
より一般的なシステムでは、 <tt>/tmp</tt> や <tt>/var/tmp</tt>、
さらに <tt>/var</tt> などをドライブ 1 に移動すると良いかもしれません。

<!--O
<sect>Appendix J: Example IV: Server with 4 Drives
-->
<sect>付録 J: 例 4: ドライブ 4 台のサーバ
<p>
<nidx>disk!example!server, 4 drives</nidx>
<!--O
This gives an example of using all techniques described earlier, short of
RAID. It is admittedly rather complicated but offers in return high
performance from modest hardware. Dimensioning are skipped but reasonable
figures can be found in previous examples.
-->
ここでは、
これまでに述べてきたすべてのテクニック (RAID 以外) をすべて使っています。
確かに少々複雑ですが、普通のハードウェアから高い性能を引き出すことができます。
実際に割り当てた大きさは省略しますが、
前の例から適当な大きさを見積もることができると思います。

<tscreen><verb>
Partition	sda		sdb		sdc		sdd
		----		----		----		----
	1	root		overview	lib		news
	2	swap		swap		swap		swap
	3	home		/usr		/var/tmp	/tmp
	4			spare root	mail		/var
</verb></tscreen>

<!--O
Setup is optimised with respect to track positioning but also for
minimising drive seeks.
-->
この設定はトラックの配置・ドライブシークのいずれに対しても
最適化されています。

<!--O
If you want DOS or Windows too you will have to use <tt/sda1/ for this
and move the other partitions after that. It will be advantageous to
use the swap partitions on <tt/sdb2/, <tt/sdc2/ and <tt/sdd2/ for
Windows swap, <tt/TEMPDIR/ and Windows temporary directory under these
sessions. A number of other HOWTOs describe how you can make several
operating systems coexist on your machine.
-->
DOS や Windows も使いたい場合は、
<tt/sda1/ をあてがってやる必要があります。
その後他のパーティションを移動させます。
スワップパーティションである <tt/sdb2/, <tt/sdc2/, <tt/sdd2/ は、
Windows セッションの間は Windows のスワップや <tt/TEMPDIR/、
Windows 自身の一時ディレクトリなどに利用できると効率が良いでしょう。
一台のマシンに複数の OS を共存させる方法については、
他にたくさんの HOWTO が出ています。

<!--O
For completeness a 4 drive example using several types of RAID is
also given which is even more complex than the example above.
-->
完全を期すために、いくつかのタイプの RAID を用いた
4 台構成のシステムについても以下に例を与えておきましょう。
上の例よりもさらに複雑な構成になっています。

<tscreen><verb>
Partition	sda		sdb		sdc		sdd
		----		----		----		----
	1	boot		overview	news		news
	2	overview	swap		swap		swap
	3	swap		lib		lib		lib
	4	lib		overview	/tmp		/tmp
	5	/var/tmp	/var/tmp	mail		/usr
	6	/home		/usr		/usr		mail
	7	/usr		/home		/var
	8	/ (root)	spare root

</verb></tscreen>

<!--O
Here all duplicates are parts of a RAID 0 set with two exceptions,
swap which is interleaved and home and mail which are implemented
as RAID 1 for safety.
-->
ダブっているものは、すべて RAID 0 のセットです。ただし swap は例外で、
これはインターリーブされている swap パーティションです。
home と mail は、安全のために RAID 1 として構成されています。

<!--O
Note that boot and root are separated: only the boot file with the
kernel has to reside within the 1023 cylinder limit. The rest of the
root files can be anywhere and here they are placed on the slowest
outermost partition. For simplicity and safety the root partition
is not on a RAID system.
-->
boot と root が分離されていることに注意してください。
boot ファイルとカーネルは 1023 シリンダよりも低位に置く必要があります。
残りの root のファイルはどこにおいてもかまいません。
ここでは最も低速な最内周のパーティションに配置しています。
わかりやすさと安全性のため、
root パーティションは RAID システムにはしていません。

<!--O
With such a complicated comes an equally complicated <tt/fstab/ file.
The large number of partitions makes it important to do the <tt/fsck/
passes in the right order, otherwise the process can take perhaps
ten times as long time to complete as the optimal solution.
-->
このような複雑な設定では <tt/fstab/ ファイルも複雑になります。
パーティションの数が増えると、
<tt/fsck/ を正しい順序で行わせることが大事になってきます。
下手な設定では、
最適な設定に比べて 10 分以上遅くなってしまうこともあり得ると思います。

<tscreen><verb>

/dev/sda8       /               ?       ?               1 1 (a)
/dev/sdb8       /               ?       noauto          1 2 (b)
/dev/sda1       boot            ?       ?               1 2 (a)
/dev/sdc7       /var            ?       ?               1 2 (c)
/dev/md1        news            ?       ?               1 3 (c+d)
/dev/md2        /var/tmp        ?       ?               1 3 (a+b)
/dev/md3        mail            ?       ?               1 4 (c+d)
/dev/md4        /home           ?       ?               1 4 (a+b)
/dev/md5        /tmp            ?       ?               1 5 (c+d)
/dev/md6        /usr            ?       ?               1 6 (a+b+c+d)
/dev/md7        /lib            ?       ?               1 7 (a+b+c+d)

</verb></tscreen>

<!--O
The letters in the brackets indicate what drives will be active
for each <tt/fsck/ entry and pass. These letters are <em/not/ present
in a real <tt/fstab/ file.
All in all there are 7 passes.
-->
括弧の内部の文字は、
それぞれの <tt/fsck/ のパスでどのドライブが使われているかを示します。
これらの文字は実際の <tt/fstab/ ファイルには<em/書いてはいけません/。
結局 7 段階のパスを使うことになりました。

<!--O
<sect>Appendix K: Example V: Dual Drive System
-->
<sect>付録 K: 例 5: ドライブ 2 台のシステム
<p>
<nidx>disk!example!system, 2 drives</nidx>
<!--O
A dual drive system offers less opportunity for clever schemes but
the following should provide a simple starting point.
-->
ドライブ 2 台の構成では、
賢い配置にするといってもできることはあまり多くありませんが、
以下のシンプルな構成を出発点とすると良いでしょう。

<tscreen><verb>
Partition	sda		sdb
		----		----
	1	boot		lib
	2	swap		news
	3	/tmp		swap
	4	/usr		/var/tmp
	5	/var		/home
	6	/ (root)


</verb></tscreen>

<!--O
If you use a dual OS system you have to keep in mind that many other
systems must boot from the first partition on the first drive. A simple
DOS / Linux system could look like this:
-->
複数 OS のシステムを使っている場合には、
他の OS の多くがブートパーティションとして
第一ドライブの第一パーティションを必要とすることに注意してください。
簡単な DOS / Linux システムは以下のようにできるでしょう。

<tscreen><verb>
Partition	sda		sdb
		----		----
	1	DOS		lib
	2	boot		news
	3	swap		swap
	4	/tmp		/var/tmp
	5	/usr		/home
	6	/var		DOSTEMP
	7	/ (root)

</verb></tscreen>

<!--O
Also remember that DOS and Windows prefer there to be just a single
primary partition which has to be the first one where it boots from.
As Linux can happily exist in logical partitions this is not a big
problem.
-->
DOS と Windows では、
基本パーティションはドライブあたり一つにしておき、
それはディスクの先頭に置いて、
そこから DOS・Windows をブートさせる構成にしておくと良いでしょう。
嬉しいことに Linux は論理パーティションにも置くことができますから、
これは大きな問題にはならないでしょう。

<!--O
<sect>Appendix L: Example VI: Single Drive System
-->
<sect>付録 L: 例 6: ドライブ 1 台のシステム
<p>
<nidx>disk!example!system, 1 drive</nidx>
<!--O
Although this falls somewhat outside the scope of this HOWTO
it cannot be denied that recently some rather large drives have
become very affordable. Drives with 10 - 20 GB are becoming
common and the question often is how best to partition such
monsters. Interestingly enough very few seem to have any problems
in filling up such drives and the future looks generally quite
rosy for manufacturers planning on even bigger drives.
-->
これはこの HOWTO の主題からは少々外れますが。
最近では確かに巨大なディスクが入手できるようになりました。
10〜20 GB のドライブが普通になりつつあり、
このようなモンスターをどう分割すべきか、
という質問がしばしば尋ねられるようになりました。
一方おもしろい事に、
このようなドライブをどうすれば一杯にできるかについての質問は
全く無いみたいですね。
さらに大きなドライブを開発しているメーカにとって、
未来はバラ色のようです。

<!--
Opportunities for optimisations are of course even smaller
than for 2 drive systems but some tricks can still be used
to optimise track positions while minimising head movements.
-->
最適化を行えるチャンスは、
2 台構成の場合に比べても当然さらに小さくなりますが、
トラックの位置に基づいた最適化やヘッド移動を最小化するためのテクニックは
多少は有効です。

<tscreen><verb>
Partition	hda		Size estimate (MB)
		----		------------------
	 1	DOS		500
	 2	boot		20
	 3	Winswap		200
	 4	data		The bulk of the drive
	 5	lib		50 - 500
	 6	news		300+
	 7	swap		128	(Maximum size for 32-bit CPU)
	 8	tmp		300+	(/tmp and /var/tmp)
	 9	/usr		50 - 500
	10	/home		300+
	11	/var		50 - 300
	12	mail		300+
	13	dosdata		10	( Windows bug workaround!)

</verb></tscreen>

<!--O
Remember that the <tt/dosdata/ partition is a DOS filesystem that
must be the very last partition on the drive, otherwise Windows
gets confused.
-->
<tt/dosdata/ パーティションは DOS ファイルシステムで、
これはドライブの最終パーティションに置かなければいけません。
これがないと Windows が混乱してしまいます。


<!--O
<sect>Appendix M: Disk System Documenter <label id="disk-documenter">
-->
<sect>付録 M: ディスクシステム記述スクリプト<label id="disk-documenter">
<p>
<nidx>disk!disk documenter</nidx>

<!--O
This shell script was very kindly provided by Steffen Hulegaard. Run it
as root (superuser) and it will generate a summary of your disk setup.
Run it after you have implemented your design and compare it with what
you designed to check for mistakes. Should your system develop defects
this document will also be a useful starting point for recovery.
-->
このシェルスクリプトは Steffen Hulegaard が提供してくださったものです。
root (スーパーユーザー) で実行するとディスクのセットアップのサマリを
生成します。設計した内容を実装しおわったらこのスクリプトを実行し、
設計と比較して間違いがないかをチェックするといいでしょう。
お使いのシステムに障害が発生した際にも、
このスクリプトの結果は復旧の出発点として役に立つでしょう。

<code>
#!/bin/bash
#&dollar;Header:&dollar;
#
# makediskdoc               Collects storage/disk info via df, mount,
#                           /etc/fstab and fdisk.  Creates a single
#                           reference file -- /root/sysop/doc/README.diskdoc
#                           Especially good for documenting storage
#                           config/partioning
#
# 11/11/1999  SC Hulegaard  Created just before RedHat 5.2 to
#                           RedHat 6.1 upgrade
# 12/31/1999  SC Hulegaard  Added sfdisk -glx usage just prior to
#                           collapse of my Quantum Grand Prix (4.3 Gb)
#
# SEE ALSO  Other /root/bin/make*doc commands to produce other /root/sysop/doc/README.*
#           files.  For example, /root/bin/makenetdoc.
#
FILE=/root/sysop/doc/README.diskdoc
echo Creating $FILE ...
echo ' ' > $FILE
echo $FILE >> $FILE
echo Produced By $0 >> $FILE
echo `date` >> $FILE
echo ' ' >> $FILE
echo &dollar;Header$ >> $FILE
echo ' ' >> $FILE
echo DESCRIPTION:  df -a >> $FILE
df -a >> $FILE 2>&1
echo ' ' >> $FILE
echo DESCRIPTION:  df -ia >> $FILE
df -ia >> $FILE 2>&1
echo ' ' >> $FILE
echo DESCRIPTION:  mount >> $FILE
mount >> $FILE 2>&1
echo ' ' >> $FILE
echo DESCRIPTION:  /etc/fstab >> $FILE
cat /etc/fstab >> $FILE
echo ' ' >> $FILE
echo DESCRIPTION:  sfdisk -s disk device size summary >> $FILE
sfdisk -s >> $FILE
echo ' ' >> $FILE
echo DESCRIPTION:  sfdisk -glx info for all disks listed in /etc/fstab >> $FILE
for x in `cat /etc/fstab | egrep /dev/[sh] | cut -c 0-8 | uniq`; do
  echo ' ' >> $FILE
  echo $x ============================= >> $FILE
  sfdisk -glx $x >> $FILE
done
echo ' ' >> $FILE
echo DESCRIPTION:  fdisk -l info for all disks listed in /etc/fstab >> $FILE
for x in `cat /etc/fstab | egrep /dev/[sh] | cut -c 0-8 | uniq`; do
  echo ' ' >> $FILE
  echo $x ============================= >> $FILE
  fdisk -l $x >> $FILE
done
echo ' ' >> $FILE
echo DESCRIPTION:  dmesg info on both sd and hd drives >> $FILE
dmesg | egrep [hs]d[a-z] >> $FILE
echo '' >> $FILE
echo Done >> $FILE
echo Done
exit
</code>
</article>

