1つの大きなパーティションにLinuxをインストールするのは本当に悪いことですか？

新しいサーバーでCentOS 7を実行します。サーバー内部のraid6に6個の300GBドライブがあります。（ストレージは主に40TBのRAIDボックスの形式で外部にあります。）単一のボリュームとしてフォーマットされた場合、内部ボリュームは約1.3TBになります。システム管理者は、1つの大きな1.3TBパーティションにOSをインストールするのは本当に悪い考えだと考えています。

私は生物学者です。私たちは常に新しいソフトウェアをインストールして実行およびテストしますが、そのほとんどは/ usr / localにあります。ただし、このシステムを使用しているコンピューターに精通していない生物学者が約12人いるため、/ homeでも大量のゴミを収集します。私たちの最後のサーバーには/に200GBのパーティションがあり、2.5年後には90％になりました。私はそれが再び起こることを望んでいませんが、専門家の助言に反したくはありません！

必要なときに必要な場所にスペースを確保するために利用可能な1.3TBを最適に使用するにはどうすればよいですか？

パーティション化の主な（歴史的な）理由は次のとおりです。

• するために、ユーザーやアプリケーションデータからオペレーティングシステムを分けます。RHEL 7のリリースまではサポートされているアップグレードパスがなく、メジャーバージョンアップグレードには再インストールが必要でした。その後、たとえば/home他の（アプリケーション）データを別のパーティション（またはLVMボリューム）に保持すると、ユーザーデータを簡単に保存できますアプリケーションデータを取得し、OSパーティションを消去します。

• ユーザーが適切にログインできず、システムがディスク領域を完全に使い果たすと、興味深い方法でシステムが失敗し始めます。複数のパーティションを使用すると、OSにハード予約ディスク領域を割り当て、ユーザーや特定のアプリケーションが書き込みを許可されている領域（例：/home /tmp/ /var/tmp/ /var/spool/ /oradata/など）から分離しておくことができ、不適切な動作のユーザーやアプリケーションの運用リスクを軽減できます。

• クォータ。管理者は、ディスククォータを使用して、個々のユーザーが使用可能なすべてのスペースを使い果たし、システムの他のすべてのユーザーへのサービスを中断することを防ぐことができます。個々のディスククォータはファイルシステムごとに割り当てられるため、単一のパーティション、つまり単一のファイルシステムは1つのディスククォータムのみを意味します。複数（LVM）パーティションは、よりきめ細かなクォータ管理を可能にする複数のファイルシステムを意味します。使用シナリオに応じて、たとえば、各ユーザーにホームディレクトリで10 GB、外部ストレージアレイの/ dataディレクトリで2TBを許可し、誰でもホームディレクトリには大きすぎるデータセットをダンプできる大きな共有スクラッチエリアを設定することができますそして、ポリシーが「満杯」になった場合でも、それが発生しても何も壊れません。

• 専用IOパスの提供。SSDと回転ディスクを組み合わせて使用​​することもできますが、それらに異なる方法で対処することをお勧めします。汎用サーバーではそれほど問題ではありませんが、データベース設定で非常に一般的なのは、特定のスピンドル（ディスク）を異なる目的に割り当ててIO競合を防ぐことです。たとえば、トランザクションログ用のディスク、実際のデータベースデータ用のディスク、一時スペース用のディスク。。

• ブート別の/bootパーティションが必要になる場合があります。歴史的に、1024シリンダーの制限を超えて起動するBIOSの問題に対処するために、最近では暗号化されたボリュームをサポートし、特定のRAIDコントローラー、SANからの起動をサポートしないHBA、またはインストーラーですぐにサポートされないファイルシステムをサポートする必要性が増えています。

• チューニング異なるチューニングオプション、または完全に異なるファイルシステムが必要になる場合があります。

ハードパーティションを使用する場合、インストール時に多かれ少なかれそれを正しくする必要があり、単一の大きなパーティションは最悪ではありませんが、上記の制限がいくつかあります。

通常、私はあなたのメインボリュームパーティション分割することをお勧めします、単一の大規模なLinuxのLVM物理ボリュームをして、論理ボリュームの作成、あなたの現在のニーズに合わせて、あなたのディスクスペースの残りのために、必要になるまで未割り当てのままにします。

その後、必要に応じてこれらのボリュームとそのファイルシステムを拡張したり（ライブシステムで実行できる簡単な操作です）、追加のボリュームを作成したりすることもできます。

LVMボリュームの縮小は簡単ですが、多くの場合、それらのファイルシステムの縮小はあまりサポートされていないため、おそらく避けるべきです。

複数のパーティションを使用する概念は、間違った場所にある完全なパーティションがシステム全体を予期せず動作させないことです。

使用可能な空き領域がなくなるまで、マシン上のプロセスがログファイルをかなり高速でいっぱいにすることを考えてください。単一パーティションのマシンでは、これにより、たとえば、システムが新しいデータを/ tmpに書き込むことができなくなります。/ tmpに書き込みたい別のプロセスがある場合、おそらくエラーで終了し、予期しない動作を引き起こします。

ユーザーまたはプロセスが通常書き込む場所（/ home、/ var、/ tmp）に異なるパーティションを使用すると、これを防ぐことができます。

どのサーバーが大きくなる傾向があるか、古いサーバーを確認することをお勧めします。コマンドラインでそれを行うことができます

du -h -d 1 / 2> /dev/null

ほとんどのデータが蓄積されている場所を確認し、次のシステムを適切に設計します。「-d 1」は、出力をフォルダーの深さの1レベルのみに制限し、読みやすくします。

単一の大きなパーティションを持つことの主な問題は、ファイルシステムがいっぱいになり、ログインできなくなる可能性があることです。

このため、ユーザーrootのホームフォルダー（/root）は外部に/homeあります。ある状況下でファイルシステムがいっぱいになると、rootでさえログインできず、システムを修復できません。

これは通常のために別々のマウントポイントを作成した理由である/var、/tmpと/home他のパーティションの1つがいっぱいになったときにシステムを修復するために、少なくともrootでログインできるようにします。

私見では、/として1つのパーティションを持つことは非常に合理的です。

ただし、lvm（論理ボリュームマネージャー）は使用できます。すべてのディスクをlvmグループとして使用しますが、/、/ home、/ usrおよびシステム管理者が好むものには小さな論理ディスクを作成します。次に、システムがフルになり始めたときに、監視を行い、必要なディスクを拡張します。lvresizeおよびresize2fsはオンラインツールであり、サーバーを再起動せずに拡張できます。ただし、ディスクを削減することはできないため、合理的に小さく開始し、必要と思われる場所を増やす必要があります。

Linuxの大きな単一パーティションのセットアップには最小限の問題がありますが、大きな見返りがあります。

パーティションのレイアウトを変更することは、少し難しくて危険なことです。これは、多くの場合、長いダウンタイムなしにはできません。

唯一の利点は、ディスクがいっぱいになった場合の問題に対してある程度の保護があることです。しかし、これらの問題は頻繁に見つかります。パーティションの1つがいっぱいで、他のパーティションのスペースがほとんど空であっても使用できない場合、状況を想像してください！

一部のプロのシステム管理者は、これについてまったく異なる意見を持っています。彼らは、複数のパーティションを持つことでシステムの信頼性が高まり、パーティション化の前にパーティションの大きさを知る必要があると言っています。私の意見では、これは単に言うことはできません、それはシステムの柔軟性の恐ろしい欠点であり、彼らの本当の動機は、彼らが単にパーティションマップで遊んでみたいということです。

lvmという名前の単純なシステムがあり、「パーティション」（用語ではボリューム）のオンザフライでの移動/サイズ変更が可能です。しかし、単一のローカル部門サーバーでは、私見では通常必要ありません。

パーティション化には、主に2つの理由があります。

1. 静的データを非静的データから遠ざける
2. パブリックデータをプライベートデータから遠ざける

最初の理由は最も明白です-ブートできないシステムを避けるために、そうでないものからファイルでいっぱいになる領域を分離する必要があり、特に/を保護する必要があります。たとえば、通常、/ varディレクトリにはログファイルが格納されます（varは「変数」を表します）。これが、/ varが/とは別のパーティションにマウントされる傾向がある理由です。

上記の2番目の理由はあまり引用されておらず（15年ほど前にVeritas Volume Managerコースで聞いたことがあります）、実際には多くの人がログインして作業を行っているシステムにのみ関係します。

効果的なパーティショニングには何か芸術があります。これが、システム管理者がそれを少しやりすぎている理由かもしれません（IMO）。ファイルシステムを徹底的に知る必要があるだけでなく、使用目的も知る必要があります。個人的には、これはかなり古風なアプローチであり、今日のサーバーの使用方法との関連性がますます低くなっていると思います。

ソフトウェア開発者として、私は特に、使用可能なディスク容量の合計に関係なく、/ tmp、/ home、/ var、および/のサイズを厳しく制限する思慮のないパーティションスキームで仮想マシンを構築する運用部門にうんざりしています。 / usrや/ optのような明らかな選択肢を個別にマウントしないでください。これらのマシンは、通常、要求したディスクスペースに残っているものをすべて、必然的にすべてをインストールしてシンボリックリンクする「/ stuff」ボリュームに入れますが、それは簡単なことではありません。最終的な結果は、実際の作業を行うよりも多くの時間をファイルのシャッフルと警告メールの送信に費やすことです。

単一のパーティションを持つことに関して本質的に「悪い」ことは何もありません。どのシステムでも、ディスクの使用状況を積極的に監視し、賢明なハウスキーピング戦略（ログのローテーション、ホームディレクトリのクォータなど）を採用する必要があります。そのため、唯一の本当の質問は次のとおりです。

したがって、特定のユースケースに合わせてシステムを効果的にパーティション分割する能力に100％自信がない限り、まったくパーティション分割しないでください。

私見それは完全にあなた次第です。最初にいくつかのことを考慮しますが、完全に相対的なものです。

• このシステムは頻繁に管理されますか？
• このシステムは1人以上のユーザーによって使用されますか？
• このシステムは、デスクトップまたはサーバー、あるいはその両方として機能しますか？

（ほぼ）任意のディレクトリをマウントポイントとみなすことができるため、いくらか成長するデータを含むものと成長するデータを含むものも考慮する必要があります。

Linuxシステム（多少成長するデータ）が実行するのに必要な量が少なく、成長するデータ（通常/ var / opt / home / srv）によって消費される量に驚くでしょう。

また、このシステムの用途をどのように定義するかにも依存します。これは、パーティション化要件の概要を示しています。LVMの使用が含まれます。

典型的なデスクトップシステムでは、ソフトウェアの負荷をインストールするために約20GBが必要になり、残りのすべてが専用の/ homeに割り当てられていれば問題ありません。LVMはシステムにわずかなオーバーヘッドを引き起こしますが、この特定のケースではそれほど大きなメリットはありません。意見は異なるかもしれませんが。

サーバーでは、インストールされたソフトウェアがデスクトップシステムほど動的である可能性は低くなります。/ tmp / var / usr / home / opt / srvなどの典型的なファイルシステムコンポーネントの実際のマウントポイントを用意することも賢明です。ここでのLVMの使用は必須ではなく推奨されています。

これにより、システムの優れたモジュール性が提供されます。また、たとえば、パーティションをVMに複製するなどのばかげたことを行うことができます。または、ddを使用してブロックレベルのバックアップを作成します。

いくつかの経験に基づいて、いくつかの注意事項があります。また、複数のマウントポイントを使用して制御を強化することを検討してください。マウントポイントに高速または低速のディスクデバイスを割り当てると、世界に違いが生じ、コスト効率が大幅に向上します。

マウンポイント/

• 1GB（/ var / usr / opt / home / tmpに個別のマウントポイントを使用する場合）
• 個別の/ homeを備えたデスクトップシステムとして使用する場合は、+ 10または+20 GB

マウントポイント/ homeを使用する場合

• 使用する場合はすべての空き領域を割り当てます、/ home ne

マウントポイント/ optを使用する場合

マウントポイント/ usrを使用する場合

• これはトリッキーなものであり、インストールされているソフトウェアベースに大きく依存しています

マウントポイント/ varを使用する場合

• これはトリッキーなものであり、インストールされているソフトウェアベースに大きく依存しています
• たとえば、データベースは、すべてではないにしても、Debianベースのシステムでデータをここに書き込みます
• 別の/ var / tmpを持つことは不合理ではありません

マウントポイント/ tmpを使用する場合

• tmpfsが存在し、RAMに/ tmpが割り当てられていると考えます
• 一部のアプリケーションがここに大量のデータを書き込む可能性があることを考慮してください

まず、なぜあなたがこの質問をここに投稿しているのか疑問に思う必要があります。ハードドライブのパーティション分割のより細かい点に関して、明らかに有能なシステム管理者と議論している生物学者です！（違反はありません。なぜシステム管理者を信頼していないのか本当に疑問に思います）。

したがって、いくつかの観察：

• 1.3 TBはもはや大きなドライブではありません。最近のデスクトップの世界では、2 TBは多かれ少なかれ標準的なSATAドライブのサイズです。

• Linux Distroのインストールに100GB以上が必要になることはほとんどありません。確かに、/（ルート）と（スワップ）のサイズは、（ルート用に）大きすぎるサイズにしたり、システム構成のガイドライン（スワップ）にしたりして、上限値として簡単に決定する必要があります。

• / homeのマウントポイントは、40TB RAIDサーバー上の何かを指している必要があります。そのデータ、つまりユーザーのホームディレクトリは、そのルートデバイス上のどこにでもある必要はありません。とにかくそれらをRAIDサーバーに配置すると、おそらくより優れた保護が得られます。そして、ほとんどの場合、容易に拡張可能なNAS施設ですが、サーバーボックスに組み込まれた小さなRAIDはそうではありません。

• おそらく、特別なソフトウェアを別のパーティション（/ usr / local / binなどのマウントポイント）に配置する必要があります。これにより、OSの更新とルートパーティションのワイプでこれを保持できます。そうしないと、OSのアップグレード/修正などを行った後、「特別な」ソフトウェアアプリを再インストールする必要が生じる可能性があります。

• システムの管理について心配する場合は、別の質問をします。建物が発火し、サーバーとRAIDボックスが破壊された後の災害復旧プロセスは何ですか？気になるデータが完全に頭の中に残っていない限り、これはすべてのユーザーがIT / sysadminの人々に尋ねるべき質問です。戦略には、「必要なハードウェアをどのように複製するか」、「バックアップして実行できるようになるまでにかかる時間」などの質問を含める必要があります。サーバーの仮想化に関する議論は、OSを再構成することなく、ハードウェアの依存関係と問題を解決するのに役立つ問題を解決するのに役立つ場合があります（変更されない「ソフト」デバイス環境で実行するように構成できるため、

• 同様に、ユーザーデータをプログラムおよびユーザーエラーデータの損失から保護するための戦略を尋ねることもできます。研究論文の非常に優れた下書きの上に空のファイルを保存したり、ユーザーが間違ったコマンド（たとえば、rm -rf *）を入力したりすると、地震や火災、その他の物理的損傷と同じくらい確実にデータが失われます。個々のファイル回復のソリューションは、大規模な災害回復に最も役立つものとは少し異なります（または可能性があります！）。

-

これにより、ユーザーデータとは別にオペレーティングシステムをバックアップ、復元、または再インストールできます。これにより、自由、独立、安全が得られます。

1. ユーザーデータの絶対的な大部分を保持したまま、別のLinuxディストリビューションに移行する方が簡単です。

2. オペレーティングシステムパーティションのバックアップを適用することにより、バグのある更新を簡単に元に戻すことができます（デュアルブートが必要です）。このバックアップはかなり古い場合もあります。これを適用して、後で安定したバージョンに更新することができます。

3. 最近適用された「メジャーアップグレード」が気に入らない場合は、オペレーティングシステムを以前のバージョンに戻すのは簡単です（デュアルブートが必要です）。

このアプローチの最大の可能性のために、デュアルブート（CentOS / CentOSの場合もあります）も構成する必要があります。これにより、オペレーティングシステムを別のオペレーティングシステムから実行しながら、あるオペレーティングシステムパーティションを上書きできます。そして、少なくとも数ヶ月に一度はシステムパーティションをバックアップする必要があります。

私の簡単な答えは、デスクトップでさえ「1つの大きなパーティション」を使用すべきではないということです。私は最近、それが「単なるラップトップ」であり、自動インストーラが単一のパーティションを使用し、ボタンをクリックしただけなので、より良い判断に反してそれを試みました。

別のディストリビューションをインストールしようとしたときに、既存のディストリビューションの上にインストーラーがインストールされないため、ドライブのパーティションを再作成する必要がありました。/ homeが独自のパーティションにある場合、/ homeはそのまま維持できます。そのため、最終的にgparted live-cdを起動してパーティションを縮小し、/ homeなどの新しいパーティションを作成し、新しいパーティションにデータを移動して、最後に新しいOSのインストーラーを起動しました。

理想的には、SSDに/を、ハードドライブに/ homeを、ハードドライブに/ varを、/ usrをアップグレードの頻度に応じてSSDまたはHDDに配置します。/ tmpをハードドライブに。私は通常、mp3や映画などの共有メディアファイル用に、/ homeからのシンボリックリンクを持つ別のパーティションを作成します。/ sbinはルートの一部であり、/ binおよび/ rootであることに注意してください。/ binと/ usr / binの違いは、/ usrはすべてのドライブがマウントされるまで使用できない可能性があるため、mountコマンドが/ usrにないことです！私は通常、他のLinuxディストリビューション用にいくつかの余分なパーティションを保持します。たとえば、本当に悪いものを台無しにした場合に備えて、ハードドライブにgpartedパーティションがあります。

サーバーを移動したり、ストレージを動的に追加したり、常時稼働したりする必要があるサーバーでは、間違いなくLVMを使用してください!!!

/ usr / localにソフトウェアをインストールする必要はありません。すべてのソフトウェアを/ homeにある別のプレフィックスにインストールできます。ほとんどのソフトウェアは、ソースからコンパイルするときに、たとえば ./configure --prefix=/home/bin

あなたは生物学者なので、rpmやdebに適切にパッケージ化されていない多くのソフトウェアに興味があるかもしれません。とにかくソースからコンパイルする必要があります。

私はユーザーの中に多くの生物学者がいるHPCシステムのシステム管理者です。彼らが要求するすべてのソフトウェアを/ apps /ファイルシステムの下にインストールします。したがって、ほとんどのソフトウェアでこれを行うことができることを知っています非常に難しい。この問題を解決するために、私の同僚と私はEasyBuild（無料でオープンソース）と呼ばれるツールで書いてきました。ソースからソフトウェアをコンパイルしてインストールし、別のフォルダーにインストールし、環境モジュールファイルを自動的に作成します。実際には、同じソフトウェアの2つの異なるバージョンをインストールでき、競合はありません。

私たちを見ていたパッケージのリストあなたがそれらの多くを認める可能性がある生物学者として、私たちはただ1つのコマンドでインストールすることができますが、;-)

免責事項：私はEasyBuildの開発者です

一般的に、初心者/入門* ixユーザーにとっては、システムの性質についてより多くの知識が得られるまで、パーティションの数を最小限に抑えることができます。ただし、複数の理由で、1つのパリティを所有することはできません。

これの最初の、そしてより公的に実用的な理由は、ほとんどのすべてのLinuxシステムがスワップパーティションを必要とすることです（一般的には1-2 * RAMの間でなければなりません） EFIパーティション（わずか500MB）。

2番目の理由は、特に状況に当てはまりますが、6x 300GBドライブを使用してRAID 6にするのは、控えめに言っても、最適な配列ではないということです。新しいテクノロジーでは、Raid 6が普遍的に優れたシステムであると称賛されていますが、ストライピングアルゴリズムがより必要であり、情報を保存するために必要なスペース（RAID 5と比較して）のサイズが大きくなっています。

RAID 6には追加のハードウェアが必要であることは言うまでもありません。私の敬意を表して、ディスク障害、ダウンタイム、災害復旧、または追加のテクニカルヘルプコストを回避するために、より大きなディスクを購入する場合に使用する必要があります。一部の、多くの人が私に同意しないことを理解しており、今後2年間でディスクのサイズが大きくなった場合（過去数年間で価格が低下したため）、より大きなアレイ用のRAID6大所得企業は当然の選択です。ただし、この場合、RAID 6の使用はお勧めしません。

2番目の（非RAIDベースの）問題に対して、ミラーリング時に1つの巨大なパーティションを作成するとうまくいく場合がありますが、効率を最大限に高めたい場合は、より大きなドライブと複数のパーティションを使用します。こうすることで、二重ディスク障害が発生した場合、特定のマウントポイントでダウンタイムが発生しないか、/ dev + / dirに依存する時間がほとんどなくなります。

少なくとも/ sys（システム、カーネルなど）を個別に実行して、何らかの理由でカーネルが起動しないと判断した場合は、単に復旧カーネル、リモートブートまたはPXE、ディスクブートなどを使用して、 d-recoveryプロセスが行われている間、情報への幅広いアクセス。

あなたの会社は、システムが機能する限りこれらのアクセントを気にかけないかもしれませんが、私は人々が物事をする理由を説明しようとしています。また、この議論に賛成および反対し、他のポイントを上げるために、他の人からより多くを聞きたいです。同意しない場合は、理由を教えてください。ポスター-リンクもいくつかご紹介します。

Linuxコミュニティスペンサーライザーへの愛

PS 特にネットワークサーバーまたは一般に公開されているシステムでは、資格情報を使用している場合でも、パーティションを分離することが最適です。他の人はここにもっと入力できます、もっとコーヒーが必要です。