ディスクの割り当てについて

Linux(debian、CentOS)で、インストール時にHDDを分割する計画なのですが、
分割のよいガイドラインが分からないのです。

分かった内容としては、
/root ・・・カーネル5周期ぐらいのコンパイル分が収まる領域があればいい？
他不明＾＾；

前インストールしたときは、以下環境で割りました。
/　　・・・5GB
/boot・・・2GB(ブート領域？)
/home・・・100GB(個人フォルダ)
/tmp・・・10GB(一時領域?)
/usr・・・40GB(プログラムインストール領域？)
/usr/local・・・40GB(プログラムインストール領域？)
/var ・・・ 40GB(ログフォルダ？)
/swap ・・・2048MB(仮想メモリ？)

というように、割りましたが、
サイズを割り当てすぎなのでしょうか？

各ディレクトリに使われる利用用途が良くわかってないのが原因とわかっているのですが。。。。

『質問』
・上記ディレクトリ構成で、linuxをインストールするときは問題ないのでしょうか？
　→WindowsならCだけあればいいみたいなことです。利用用途としては、DMZでの利用、DBでの利用等を考えています。
・「代表的なサイズ」と「なぜそのサイズでいいのか？」を教えていただけないでしょうか。
　→やはり、自動で割り当てというのは、サーバーを構築する人間としては問題だと思っています。

どなたかご教授のほう宜しくお願いします。

No.1 ベストアンサー 回答者： nora1962 回答日時： 2011/10/10 01:36

そんなに詳しいわけではありませんが、Linuxでもswap領域は切り分けなければならないですけど、その他の領域はまとめることが可能なようです。

ただ/boot」は分離してDISKの先頭の方に確保するのが安全みたいです。
http://www.obenri.com/_install_cent5/disk_cent5. …
（現在は大丈夫かもしれませんが）
で、残りをすべて「/」にマウントすることは可能です。
「/boot」の容量も2GBもいりません。
「/home」はWindowsで言う「Users」「Documents and Settings」に当たるのと、ユーザー独自でインストールしたいプログラムの格納先になります。
「/var」には「/var/log」以外にCentOSの場合はPostgreSQLとか「/var/www」（Apacheのルートディレクトリ）などが入ります。
正直一基のDISKにインストールするのなら、前環境ほど細かく分ける必要はないと思います。
DBサーバーに使用し、複数台のDISKを使用するということなら、データベースファイルやWAL（トランザクションログ）の領域を分散して配置するのがいいと思いますが。

この回答へのお礼

簡潔に書いていただき、ありがとうございました。
たしかに/bootだけは、自動でも作成されてました。
/の配下に、ディレクトリが格納されていることも確認しました。

お礼日時：2011/10/25 19:21

No.2 回答者： vaidurya 回答日時： 2011/10/10 01:37

分割しなくてはならないというのが、今や勘違いですけどね。

ディレクトリーとしての分割や、クオータによる制限を考えると
一台のHDDを分割して使う必然性は無いのです。

古典的には、分割することが普通でしたし
swapについては、異なるファイルシステムとして構築するのが標準なので
分割するのが今も普通です。

でも、たとえばUbuntuを自動インストールすると
パーティションは、swapとシステムの2つしか作られませんし…
それで、不都合に出会うことも、普通はありません。


Windowsでは、システムとデータの分割を、事前に計画する必然性がありますが…
UNIX系のファイルシステム管理では、/dev/sda1の中にあった/homeを
容量不足で、別のHDDに変更しようという時にも
OSでのマウント設定を変更するだけで、アプリケーションごとの設定や
ディレクトリー記憶機構の整合性維持に手間がかかるということがありません。
(Windowsでは、各アプリについて、C:からD:への設定変更の手間がかかります)

ですから、必要に応じて、後から変更することは自由ですし、困難ではありません。


パーティションを分割するデメリットとしては、既にとまどっている適切な容量割り当てや
物理的なシーク量の増大といった問題があります。

反面パーティション分割のメリットとしては、ファイルシステムチェックが短時間で終わる。
標準のext2,3,4以外のxfs,jfs,RaiserFSなど、用途に合わせて選択しやすい。
(起動パーティションには使えないファイルシステムもあります)
容量を、他の用途によって食いつぶされてシステムが異常動作することを避けやすい。

といったものがありますが…、そう大きなメリットでは無い場合も多いでしょう。
ジャーナリングファイルシステムではチェック時間も短めですしね。


一度、分割せずに運用してみて、ある程度経ってからduで状況を見れば
どのディレクトリーにどのくらいの容量が必要なのかはわかると思います。

それで、容量不足に出会うようなことがあれば
追加HDDの運用として、はじめて割り当てを考えれば充分です。


私自身は、MythTVの大量ログファイルのトラブルくらいしか容量問題に出会ったことはありません。
そもそも、LinuxをデスクトップPCとして使う程度なら、10GBでも余裕なのですから…
(ソースコードを展開することが多ければ、10GBでは全然足りませんけど…)


ちなみに、MythTVを無計画に運用すると、/var/lib/mythtv/recordings,livetvが容量を食いつぶし
/var/log/mythtvが容量を食いつぶし、/var/lib/mysqlの容量不足でMySQLが稼働不能になります。
myisamchkの世話にかかるようなことにもなります。


うちは、起動ディスクが64GBのSSDで、/var/lib/mythtvを別ディスクにしておいたんですが
そこの空きが無くなったというエラーログを大量に吐き出して、/var自体が溢れたわけです orz

これ、/varを別パーティションに分けていても、何の意味もありません。
ですから、こういう兼ね合いは、よくよく考えて、その上で分ける必要があります。


うちの例では、mythtvのログとMySQLのデータを、別々のパーティションに置くように
パーティション分割を行なうか、あるいはログディレクトリーを
クオータで制限することで解決できたのだろうと思います。

まぁ、引越先がデジアナ変換の無いアパートだったので
当面、MythTVは止めているんですけどね。
(そういうわけで、クオータの使い方は学んでいません。日常的には不要ですし)

この回答へのお礼

linuxサーバーを立てる=ディスクを割る。
という考えでいました。

非常に詳細な情報教えていただきありがとうございます。

お礼日時：2011/10/25 19:19

No.3 回答者： gtx456gtx 回答日時： 2011/10/10 10:13

>やはり、自動で割り当てというのは、サーバーを構築する人間としては問題だと思っています。

何故？

私は、過去に経験のないシステム構成の場合はデフォルトを選択するようにします。　前提として、テスト環境で暫く運用し、この内容を検討して本格稼動のシステムを再構築するということですが・・・
それでも最初に構築する際は、各パーティションの使用率を３０％以下になるようにしています。

>利用用途としては、DMZでの利用、DBでの利用等を考えています。
ＤＭＺもＤＢも運用次第で、殆ど変化しない場合もあるし、次第に増加する場合もあるので・・・判断できるのご質問者様しかいないと思います。

また、パーティション分割も/bootなど単独でパーティションとした方が良いものを除いて、パーティション分割しない人と細かくパーティション分割する人に分かれて、どっちでも良いと思っていますが。

LVMなど利用するとパーティションを拡張することもできるので・・・パーティション分割に必要以上に拘りを持つ意味が無くなっているように思います。

この回答へのお礼

>LVMなど利用するとパーティションを拡張することもできるので・・・パーティション分割に必要以上に拘りを持つ意味が無くなっているように思います。

確かにおっしゃられると通りだとおもいました。
ありがとうございました。

お礼日時：2011/10/25 19:17

No.4 回答者： onosuke 回答日時： 2011/10/10 17:20

>各ディレクトリに使われる利用用途が良くわかってないのが原因とわかっているのですが。

。。。

観点がちょっとずれているように思います。
そもそも、「何故HDD分割しなければならないのか？（or 何故HDD分割が不要なのか？）」
上記の理由（理屈）を抑えていないのが、原因ではないでしょうか？

パーティション分割する理由には、
　・ハードウェア、ソフトウェアの制約による理由
　・運用環境に依存する理由
　・過去には問題だった理由（採用技術/ソフトウェアの進歩で現在は問題とならない）
などがあります。

また、パーティション分割には、以下の欠点もあります。
　・容量の利用効率が下がる。
　　　⇒容量見積りを誤ると、後で特定領域のみが容量不足となり困る。
　・管理が面倒。
　　　⇒何ごとも、シンプル・イズ・ベスト。
　　　　数が多いと、それだけで面倒です。

パーティション分割の欠点を上回る利点がない限りは、
パーティション分割すべきではないでしょう。

容量の話は、「パーティション分割する/しない」を決めた上で、
考えるべき話だと思います。

さて、以上の話を鑑みた上で、
質問文にあるような細かいパーティション分割は必要でしょうか？
OS標準のパーティション分割をベースに再度見直しすることを、
オススメします。


＜ハードウェア、ソフトウェアの制約による理由＞
/boot…「1024シリンダ以上の領域からブートできない問題」
　　　　「複雑なファイルシステムをbootloaderが理解できない問題」があるため、
　　　　　ディスク先頭に、小容量のext2パーティションを用意する。
　　　　　なお、高機能なbootloaderや最近のハードウェアでは、上記制約を無視できる場合もある。

＜運用環境に依存する理由＞
/home… 数百人、数千人が利用するマルチユーザ環境では、
　　　　性能面、可用性、安全性などを考慮して、専用物理ディスクを割り当てるべきである。
　　　　　⇒従って、パーティション割りも別にする。
　　　　　⇒逆に、１人～数人しか使わない環境であれば、他と区別する必要性はない。
　　　　　⇒サーバ等で、運用管理者の作業領域（サービス運用環境に影響与えないように）
　　　　　　として、別枠にしておく場合もある。

swap領域…Linuxでは、Windowsのようにスワップファイルを利用する方法もあり、
　　　　　スワップファイルを利用する場合、swap領域のパーティションは不要。
　　　　　でも、専用パーティションの方が性能は良い。

/var、/tmp…非常に大量のログファイルや一時ファイルを作成するアプリがある場合、
　　　　　　iノード枯渇、ファイルシステム性能劣化の影響範囲を極小化するため、
　　　　　　別パーティションに分割して、性能、可用性、安全性を確保する。

その他…rawdeviceやblockdeviceを利用するため（DBMSなどの性能向上が目的）に
　　　　パーティション分けする。

＜過去には問題だった理由＞
　・頻繁なファイル更新により、ファイルシステムの性能劣化が発生する。
　　　【過去の主な対策】
　　　　－/var、/tmp、/home等、更新頻度の高い箇所を分ける。
　　　　　さらに、定期的にファイルシステムを再編成（バックアップ/リストア）
　　　　　することで性能劣化を回避する。
　　　【今の主な対策】
　　　　－ファイルシステムの技術革新により、性能劣化が昔に比べて少なくなった。

　・巨大なファイルシステムは、fsckに長時間かかる。
　　　【過去の主な対策】
　　　　－容量が大きくならないよう、パーティションを細かく分割する。
　　　　－マシンが飛んだら、/var や /tmp はあきらめる（再フォーマットしてしまう）
　　　【今の主な対策】
　　　　－ジャーナリングファイルシステムを利用することで、fsck時間を短縮する。

この回答へのお礼

非常に細かな情報ありがとうごじました。
リナックス系のサーバー構築をしたことがなかったので、
論点がずれてました。

お礼日時：2011/10/25 19:16

No.5 回答者： wingstar 回答日時： 2011/10/10 17:38

> やはり、自動で割り当てというのは、サーバーを構築する人間としては問題だと思っています。

昔はHDDの容量も限られていたので、あれやこれやと考えてやりましたが、このご時世では特に何も考えずに自動でやってますね。
逆に各ディレクトリが、どのくらいの容量が必要なのかわかっているなら、別にパーティション分けしなくてもいいかと。

パーティションを分けていたことによるトラブルが発生するなら、私は自動かワンパーティションの方が良いと思ってます。