Linuxを1つの大きなパーティションにインストールするのは本当に悪いことですか？
CentOS 7を新しいサーバーで実行します。サーバー内部のraid6に6 x 300GBドライブがあります。 （ストレージは主に40TB RAIDボックスの形で外部にあります。）内部ボリュームは、単一ボリュームとしてフォーマットされた場合、約1.3TBになります。私たちのシステム管理者は、1つの大きな1.3 TBパーティションにOSをインストールすることは本当に悪い考えだと考えています。
私は生物学者です。私たちは常に実行してテストするために新しいソフトウェアをインストールします。そのほとんどは/ usr/localにあります。ただし、システムを使用しているコンピューターに精通していない生物学者が約12人いるため、/ homeにも多くのくずを集めています。私たちの最後のサーバーには/のための200GBのパーティションがあり、2.5年後には90％使用されていました。私はそれが再び起こることを望んでいませんが、専門家のアドバイスに反対したくありません！
1.3TBの空き容量を使用して、必要なときに必要な場所で空き容量を確保しながら、システム管理者にメンテナンスの悪夢をもたらさないようにするにはどうすればよいですか？
パーティション分割の主な（歴史的な）理由は次のとおりです。
toオペレーティングシステムをユーザーおよびアプリケーションデータから分離します。 RHEL 7のリリースまでは、サポートされているアップグレードパスはありませんでした。メジャーバージョンのアップグレードでは、再インストールが必要で、たとえば、_
/home_およびその他（アプリケーション）が必要でした別々のパーティション（またはLVMボリューム）のデータを使用すると、ユーザーデータとアプリケーションデータを簡単に保存し、OSパーティションをワイプできます。ユーザーが適切にログインできず、ディスク領域が完全に不足すると、システムが興味深い方法で失敗し始めます。複数のパーティションを使用すると、OSにハードリザーブディスク領域を割り当てて、ユーザーや特定のアプリケーションが書き込みを許可されている領域（たとえば、_
/home /tmp/ /var/tmp/ /var/spool/ /oradata/_など）とは別に保つことができます不適切な行動をとるユーザーやアプリケーションの運用上のリスク。クォータ。ディスククォータを使用すると、管理者は個々のユーザーがすべての使用可能なスペースを使い果たして、システムの他のすべてのユーザーへのサービスが中断されるのを防ぐことができます。個々のディスククォータはファイルシステムごとに割り当てられるため、単一のパーティション、つまり単一のファイルシステムは、1つのディスククォータのみを意味します。複数（LVM）パーティションとは、より詳細なクォータ管理を可能にする複数のファイルシステムを意味します。使用シナリオによっては、たとえば、各ユーザーにホームディレクトリに10 GB、外部ストレージアレイの/ dataディレクトリに2 TBを許可し、ホームディレクトリには大きすぎるデータセットをだれでもダンプできる大きな共有スクラッチ領域を設定することができます。そして、ポリシーが「完全でいっぱい」になるところですが、それが起こっても何も壊れません。
専用IOパスを提供します。SSDと回転ディスクの組み合わせがあり、それらを異なる方法で処理するのに適しています。それほど問題ではありません。汎用サーバーでは、データベースのセットアップでは非常に一般的ですが、特定のスピンドル（ディスク）をさまざまな目的に割り当てて、IO競合を防止します。たとえば、トランザクションログ用に別のディスク、実際には別のディスクを使用します。一時スペース用のデータベースデータと個別のディスク。
Boot別の_
/boot_パーティションが必要になる場合があります。歴史的には、1024シリンダーの制限を超えて起動するBIOSの問題に対処するために、最近では、暗号化されたボリュームをサポートする要件、特定のRAIDコントローラーをサポートするための要件、HBAはSANまたはファイルからの起動をサポートしない-インストーラーなどですぐにサポートされないシステム.チューニング異なるチューニングオプションまたは完全に異なるファイルシステムが必要になる場合があります。
ハードパーティションを使用する場合、インストール時に多かれ少なかれそれを正しく取得する必要があり、単一の大きなパーティションは最悪ではありませんが、上記の制限のいくつかが付属しています。
通常、メインボリュームを1つの大きな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の個別のマウントポイントを作成して、他のパーティションのいずれかがいっぱいになったときに、少なくともrootとしてログインしてシステムを修復できるようにする理由です。アップ。
私見、1つのパーティションを/として持つのはかなり合理的です。
ただし、lvm（論理ボリュームマネージャー）を使用できます。すべてのディスクをlvmグループとして使用しますが、/、/ home、/ usr、およびシステム管理者が好むものには小さな論理ディスクを作成します。次に、システムがいっぱいになり始めたら、監視をオンにして、必要なディスクを拡張します。 lvresizeとresize2fsはオンラインツールであり、サーバーを再起動せずに拡張できます。ただし、ディスクを削減することはできないため、適度に小さく開始し、必要に応じて増やす必要があります。
Linuxの大きな単一パーティションのセットアップに関する問題は最小限ですが、大きなメリットがあります。
パーティションレイアウトの変更は少し難しくリスクが伴いますが、多くの場合、長いダウンタイムなしでは実行できません。
その唯一の利点は、ディスクがいっぱいになる問題に対してある程度の保護があることです。しかし、あなたはこれらの問題を多く見つけることがよくあります。パーティションの1つがいっぱいで、ほとんど空であっても、他のパーティションのスペースを使用できない状況を想像してください！
一部の専門的なシステム管理者は、これについてまったく異なる意見を持っています。彼らは、複数のパーティションがあるとシステムの信頼性が高まるため、パーティションを作成する前に、パーティションの大きさを知っておく必要があると述べています。私の意見では、これは単純に言うことはできません、それはシステムの柔軟性にひどい欠点であり、彼らの本当の動機は、彼らが単にパーティションマップで遊んでみたいということです。
lvm という名前のシンプルなシステムがあり、「パーティション」（その用語では、ボリューム）をオンザフライで移動/サイズ変更できます。ただし、単一のローカル部門サーバーでは、IMHOは通常必要ありません。
パーティショニングには主に2つの理由があります。
- 静的データを非静的データから遠ざけるには
- パブリックデータをプライベートデータから遠ざけるには
1つ目の理由は最も明白です。起動できないシステムを回避するために、ファイルでいっぱいになる領域を、そうでない領域から分離する必要があり、特に/を保護する必要があります。たとえば、/ varディレクトリは通常、ログファイルが格納される場所で（varは「変数」を表します）、/ varが/とは別のパーティションにマウントされる傾向があるのはこのためです。
上記の2番目の理由はあまり言及されておらず（約15年前にVeritas Volume Managerコースで最後に聞いた）、これは実際に、多くの人がログインして作業を実行しているシステムにのみ関連しています。
効果的なパーティション分割には芸術のようなものがあります。これがおそらく、システム管理者が少し行き過ぎている（IMO）理由です。ファイルシステムを完全に知る必要があるだけでなく、使用目的も知っておく必要があります。私は個人的には、サーバーが現在使用されている方法との関連がますます古くなっている、昔ながらのアプローチだと思います。
ソフトウェア開発者として、私は特に、使用可能な合計ディスク容量に関係なく、/ tmp、/ home、/ var、/のサイズを厳しく制限する無計画のパーティションスキームを使用して仮想マシンを構築するOps部門に特にうんざりしています。/usrや/ optなどの明白な選択肢を個別にマウントしないでください。これらのマシンは通常、要求されたディスクスペースから残されたものをすべて「/ stuff」ボリュームに入れ、必然的にすべてをインストールしてシンボリックリンクすることになりますが、それは決して慰めではありません。その結果、実際の作業を行うよりも、ファイルをシャッフルしたり警告メールを送信したりするのに多くの時間を費やすことがよくあります。
単一のパーティションを持つことは本質的に「悪い」ものではありません。どのシステムでも、ディスクの使用率を積極的に監視し、賢明なハウスキーピング戦略（ログのローテーション、ホームディレクトリの割り当てなど）を採用する必要があります。そのため、本当の疑問は、個別のファイルシステムをいくつ心配する必要があるかです。
したがって、私はこう言います：特定のユースケースに合わせてシステムを効果的にパーティション分割する能力に100％自信がある場合を除き、まったくパーティション分割しないでください。
まず第一に、なぜあなたがこの質問をここに投稿しているのか、どうやらハードドライブのパーティション分割の細かい点について、有能なシステム管理者と議論している生物学者であるのか、質問しなければなりません。 （あなたがあなたのシステム管理者を信頼していない理由を本当に不思議に思っています）.
だから、いくつかの観察：
1.3 TBは、もはや大容量ドライブではありません。2TBは、最近のデスクトップの世界では多かれ少なかれ標準のSATAドライブサイズです。
linux Distroのインストールでは、100GB以上を必要とすることはほとんどありません。確かに、/（ルート）と（スワップ）のサイズは、それらを（ルートの）サイズを大きくするか、システム構成ガイドライン（スワップ）で大きくすることにより、上限数として簡単に決定できます。
/ homeのマウントポイントは、40TB RAIDサーバー上の何かを指している必要があります。そのルートデバイス上のどこにでも、そのデータ、つまりユーザーのホームディレクトリは必要ありません。それらをRAIDサーバーに配置すると、おそらく保護が強化されます。そして、それはたぶん容易に拡張可能なNASファシリティですが、サーバーボックスに組み込まれた小さなRAIDはおそらくそうではありません。
oSの更新やルートパーティションのワイプ全体でこれを維持できるように、おそらく特別なソフトウェアを別のパーティション（/ usr/local/binのマウントポイントなど）に配置する必要があります。そうしないと、OSのアップグレード/修正/その他の後に「特別な」ソフトウェアアプリを再インストールしなければならない可能性があります。
システムの管理について心配したい場合は、別の質問をします。建物が火事になり、サーバーとRAIDボックスが破壊された後の障害回復プロセスは何ですか。気になるデータが完全に頭に残っていない限り、これはすべてのユーザーがIT /システム管理者に尋ねるべき問題です。戦略には、「必要なハードウェアをどのように複製するか」、「バックアップして実行できるようになるまでにかかる時間」などの質問を含める必要があります。サーバーの仮想化に関するいくつかの議論は、ハードウェアの依存関係に関する問題を解決し、OSを再構成する必要なしに物事をバックアップおよび実行するのに役立つ可能性があります基盤となるハードウェアは完全に異なります）
同様に、プログラムおよびユーザーエラーデータの損失からユーザーデータを保護するための戦略について尋ねることもできます。研究論文の非常に優れたドラフトに空のファイルを保存したり、ユーザーが間違ったコマンド（たとえば、rm -rf *）を入力したりすると、地震や火事などの物理的な損傷と同じくらい確実にデータが失われます。個別のファイルリカバリのソリューションは、大規模な災害復旧に最も役立つソリューションとは少し異なります（または異なる可能性があります）。
-
私見それは完全にあなた次第です。最初はいくつかのことを考慮してください。
- このシステムは頻繁に管理されますか？
- このシステムは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を使用する場合
- これはトリッキーなもので、インストールされているソフトウェアベースに大きく依存しています
- たとえば、すべてのLinuxではないにしても、データベースはここにDebianベースのシステムでデータを書き込みます
- 別の/ var/tmpがあることは不合理ではありません
マウントポイント/ tmpを使用する場合
- tmpfsが存在し、/ tmpがRAMに割り当てられていることを考慮
- 一部のアプリケーションがここに大量のデータを書き込む可能性があることを考慮してください
これにより、ユーザーデータから独立してオペレーティングシステムをバックアップ、復元、または再インストールできます。これにより、自由、独立、安全が得られます。
ユーザーデータの絶対的な大部分を維持しながら、別のLinuxディストリビューションに移行する方がはるかに簡単です。
オペレーティングシステムパーティションのバックアップを適用することで、バグのある更新を簡単に元に戻すことができます（デュアルブートが必要です）。このバックアップはかなり古い可能性もあります。それを適用して、後で安定したバージョンに更新できます。
最近適用された「メジャーアップグレード」が気に入らない場合は、オペレーティングシステムを以前のバージョンに戻すのは簡単です（デュアルブートが必要です）。
このアプローチの最大の可能性については、デュアルブート（CentOS/CentOSの場合もあります）も構成する必要があります。これにより、オペレーティングシステムを別のオペレーティングシステムから実行しているときに、オペレーティングシステムのパーティションを上書きできます。そして、確かに、少なくとも数か月に一度はシステムパーティションをバックアップする必要があります。
ソフトウェアを/ usr/localにインストールする必要はありません。すべてのソフトウェアを/ homeにある別のプレフィックスにインストールできます。ほとんどのソフトウェアは、ソースからコンパイルするときに、たとえば、 ./configure --prefix=/home/bin
あなたは生物学者なので、rpmやdebに適切にパッケージ化されていない多くのソフトウェアに興味があり、とにかくソースからコンパイルする必要があります。
私は、HPCシステムのシステム管理者であり、ユーザーの中に多くの生物学者がいます。彼らが要求するすべてのソフトウェアを/ apps /ファイルシステムにインストールしているので、ほとんどのソフトウェアでこれを実行できることはわかっていますが、場合によっては非常に難しい。この問題を解決するために、私の同僚は EasyBuild （無料でオープンソース）と呼ばれるツールを書いています。ソースからソフトウェアをコンパイルしてインストールし、別のフォルダーにインストールして、自動的に 環境モジュール ファイルを使用できるため、実際には同じソフトウェアの2つの異なるバージョンをインストールでき、競合は発生しません。
ご覧ください パッケージのリスト たった1つのコマンドでインストールできます。生物学者はそれらの多くを認識しているかもしれません。;-)
免責事項：私はEasyBuildの開発者です
私の短い答えは、デスクトップでも「1つの大きなパーティション」を使用してはならないということです。 「ラップトップ」であり、自動インストーラが単一のパーティションを使用していたので、私は最近、より良い判断に逆らってそれを試して、ボタンをクリックしただけでした。
別のディストリビューションをインストールしようとすると、インストーラーが既存のディストリビューションの上にインストールされないため、ドライブを再パーティション化する必要がありました。独自のパーティション上にある場合、/ homeをそのまま維持できます。そのため、gparted live-cdを起動してパーティションを縮小し、/ homeなどの新しいパーティションを作成して、データを新しいパーティションに移動し、最後に新しいOSのインストーラーを起動しました。
理想的には、/をSSDに、/ homeをハードドライブに、/ varをハードドライブに、/ usrは、アップグレードを計画する頻度に応じてSSDまたはHDDに置くことができます。/tmpをハードドライブに。私は通常、mp3や映画などの共有メディアファイル用に別のパーティションを作成し、/ homeからシンボリックリンクを作成します。/sbinはrootの一部であり、/ binおよび/ rootであることに注意してください。/binと/ usr/binの違いは、/ usrはすべてのドライブがマウントされるまで使用できない可能性があるため、mountコマンドを/ usrに含めることはできないということです。私は通常、他のLinuxディストリビューション用にいくつかの追加のパーティションを保持します。たとえば、本当に悪いものを台無しにした場合に備えて、別のライブシステムでリカバリ作業を行う準備ができているので、gpartedはハードドライブにあります。
物事を移動したり、ストレージを動的に追加したり、常時稼働したりする必要があるサーバーでは、確実にLVMを使用してください!!!
一般に、初心者/入門* ixユーザーにとっては、システムの性質についてさらに学習するまで、パーティションの数を最小限に抑えることができると思います。ただし、複数の理由から、単純に1つのパーティションを使用することはできません。
これの最初の、より公的な実用的な理由は、ほとんどすべてのLinuxシステムがスワップパーティションを必要とすることです（通常、RAMは1〜2 * RAMの間にある必要があります）また、個別のシステム、ブートまたはホームパーティションが必要で、UEFIの場合はLinuxシステムをブートしますEFIパーティション（わずか500MB）。
2番目の理由は、特にあなたの状況に当てはまることですが、300 GBのドライブを6台使用してRAID 6にすることは、言うまでもなく、最適な配置ではありません。新しい技術では、RAID 6をより優れたシステムとして評価していますが、ストライピングアルゴリズムはより必要であり、情報を格納するために必要なスペースは（RAID 5と比較して）より大きくなります。
RAID 6には追加のハードウェアが必要であることは言うまでもありません。私の尊敬すべき意見では、ディスクの故障、ダウンタイム、災害復旧、または追加の技術支援コストを回避するために、より大きなディスクを購入する場合にこれを使用する必要があります。一部の人、おそらくは多くの人が同意しないことを理解しています。今後2年間でディスクのサイズが大きくなった場合（過去数年間で価格が下がったため）、大規模なアレイのRAID6および大規模な所得企業は当然の選択です。ただし、この場合、RAID 6の使用はお勧めしません。
2番目の問題（非RAIDベース）では、ミラーリング時に巨大なパーティションを1つ作成することで問題が解決する場合がありますが、効率を最大化するには、より大きなドライブと複数のパーティションを使用します。このようにして、二重ディスク障害が発生した場合、特定のマウントポイントでダウンタイムが発生しないか、/ dev +/dirによってはほとんどダウンタイムが発生しません。
少なくとも/ sys（システム、カーネルなど）を個別に実行するようにします。これにより、何らかの理由でカーネルが起動しないと判断した場合は、単にリカバリカーネル、リモートブートまたはPXE、ディスクブートなどを使用して、 d-recoveryプロセスが行われている間、情報への幅広いアクセス。
システムが機能する限り、あなたの会社はこれらのアクセントを気にしないかもしれませんが、私は人々が物事をする理由を説明しようとしています。また、この議論に賛成または反対して、他の人からもっと多くの意見を聞き、他の点を提起したいと思います。同意しない場合は、その理由を教えてください。ポスター-私はPMあなたにもいくつかのリンクをつけます。
Linuxコミュニティスペンサーライザへの愛
[〜＃〜] ps [〜＃〜]特に、一般に公開されているネットワークサーバーやシステムでは、クレデンシャルを介していても、パーティションを分離するのが最善です。他の人はもっとここに入力できます、もっとコーヒーが必要です。