最適なUNIXファイルシステムパーティション+セットアップ戦略


16

UNIX用の新しいシステムディスクをパーティション分割する場合、デスクトップとサーバーの両方、またはその両方で望ましい戦略は何ですか?

ディスクパーティションレイアウト、ファイルシステムフォーマットとオプション、マウントポイント、RAIDレベル、LVMグループとボリューム、暗号化、およびその他の関連設定を含めてください。


質問は、これのほとんどの複製のようです(serverfault.com/questions/1145/…)。
ゾレダチェ2009年

これは、ワークステーション、テストサーバー、または完全に成熟したオンラインサーバーですか?
djangofan 09

回答:


9

私はこの種の問題に対するLVMのファンです。/ boot用のスペースが必要です(約100MB使用します)。動的に拡大および縮小(または少なくとも拡大)できるファイルシステムと組み合わせると、小さなパーティションについて再度考える必要がなくなります。

私のデスクトップでは、すべてのパーティションのファイルシステムとしてXFSを備えたLVMを使用しています。私はできるだけ小さく作成し、より多くのスペースが必要になるとそれらを成長させます。


7

Linuxの場合は、別の/ bootを用意します。

他のUnixバリアントについては、通常、/および/ varのパーティションを推奨しています。データは通常/ u001、/ u002などにマウントされます。

以前は、ディスク領域が限られているため、パーティションを大きく分割する必要があり、単一のパーティションでシステム全体をダウンさせたくありませんでした。現在利用可能なストレージが大幅に増加し、豊富なサイズ変更と仮想化オプションが利用できるようになったため、IMOの多くのパーティションの必要性は低下しました。それは、多くのパーティションがあるときに物事を動かすのが面倒であるという事実と相まって、より少ないもので逃げることができれば、それを行うことを意味します。

32GBのメモリがある場合、2xRAMとしてスワップすることは意味がありません。そのため、「ルール」は実際のガイドラインであり、現在利用可能な新しいハードウェアに照らして意味をなさないものもあることを忘れないでください。


2
/ homeにもっとスペースが必要な場合は、常に新しいハードドライブをマウントすることができます。
スポイケ

1
+1-ほとんどのシステムでクレイジーパーティションゲームの必要性を軽視していることに同意します。何らかのアプリケーションのために/ varが高速ディスク上に存在する必要があることがわかっている場合は、そうしてください。たいていの場合、本番システムでクレイジーなパーティションゲームに出くわしたとき、それは小さなパーティションの塊に切り分けられた単一のハードウェアRAID-1ボリュームであり、すべてがいっぱいになるのを待って、サイズを変更する必要があります管理者、どうやら)。ある種の複雑なパーティション構成のアプリケーションがあることがわかっている場合は、それを選択してください。そうしないなら、あなたはしません。
エヴァンアンダーソン

5

適切なパーティション構造を計画することは、システムの使用方法を実際に知ることに大きく依存します。システムが何をしているかを考慮しないランダムなアドバイスは、特に有用ではありません。

すべての派手なファイルシステムが役に立つ場合がありますが、安定したシステムが必要な場合は、他の何かを使用する非常に正当な理由がない限り、「標準」ファイルシステム(つまりext3)に固執することをお勧めします。

RAIDは優れています。ハードドライブの故障が多すぎるため、すべてのパーソナルコンピューターで常にRAID1を実行しています。

dm-cryptなどの暗号化は、システムがポータブルデバイスである場合、価値の高いデータを持っている場合、または単に偏執的な場合に適しています。

パーティションを計画する際には、Filesystem Hierarchy Standardのようなものと、選択したUNIXが標準から逸脱するかどうか/どのように逸脱するかをよく理解しておくと非常に役立ちます。

LVMを使用すると、再起動することなく、将来の気分の変更やパーティションの調整がはるかに簡単になります。また、スナップショットを作成する機能により、適切なバックアップを簡単に作成できます。LVMを使用し、すぐにすべてのスペースを割り当てないでください。


5

FSタイプ以外にパーティションを作成するのには、2つの非常に良い理由があります。

  1. システムの機能に影響を与えるアプリケーションからの流出を防ぎます。アプリがいっぱい/usrになった場合/var、システムを続行してログを記録できるように、いくつかのスペースを残しておくと便利です。

    ジャウダーは、これは今日のハードディスクのサイズによって否定されると言った-私はこれが厳密に真実だとは思わない。ドライブは大きくなる可能性がありますが、引き渡すデータは増え続けています。満足する必要はありません。

  2. マウントオプション。各パーティションに採用するアクセス許可をより慎重に定義できます。たとえば、/tmpWebアプリケーションにサービスを提供するマシンの一般的な攻撃ベクトルであるため、ファイル、特にsuidの実行を許可しないことをお勧めします。刑務所を走らせているのでない限り、デバイスノードはどこにも見えないはず/devです。等々。

例えば。

/ noatime  
/tmp noatime,nodev,nosuid,noexec  
/var noatime,nodev,nosuid  
/usr noatime,nodev  
/home noatime,nodev,nosuid  

4

物理ディスクのパーティション分割
最低2つのディスクから開始します。

#1 100MB、ID = 83(Linux)、ブートフラグON
#2残り、ID = FD(Linux Raid Auto)

100MBパーティションは/ bootボリューム用です。柔軟性を確保するために、これをすべてのドライブ(ブート以外でも)に残しておき、後でどのドライブでもブートできるようにします。ディスクのサイズが一致しない場合、または奇数(500GB、250GBx2)がある場合は、500GBドライブのパーティションを分割して小さいディスクに一致させます。

RAID
に100MBのパーティションを使用sdaしてsdbのためにRAID1(ミラー)ボリュームを作成します/boot。これはになりmd0ます。

md0 / boot 100MB Ext2

/ bootでエキゾチックなFSを使わないでください、それは価値がありません。

残りのスペースはさまざまな方法で設定できます。64Kチャンクと「2ファーコピー」を使用して速度を上げるRAID10(ミラー/ストライプ)を選択します。これにより、ドライブを段階的にアップグレードする柔軟性が大幅に向上します。他のオプションは、RAID5 / 6を実行することです。ただし、使用可能なスペースは最小のパーティションに制限され、同じデバイスのパーティションを使用しないでください。新しいRAIDアレイに名前を付けmd1md2とになります。

LVM
を除くすべてのRAIDアレイをmd0取得し、という名前の単一のLVMボリュームグループに入れますlvm_vg0。RAID5ボリュームとRAID10ボリュームがある場合、それらを結合しないことをお勧めしますが、害はないと思います。

残りのシステムマウント用にVG0をパーティションします。必要に応じてスペースを追加するのは比較的簡単であるため、これらの数値は多少控えめになる可能性があることに注意してください。

lvm_vg0-root / 8GB Ext3 / ReiserFS(コアディストリビューションファイル)
lvm_vg0-home / home 20 + GB Ext3 / ReiserFS(ユーザーデータ、ドキュメント)
lvm_vg0-data / data 60 + GB XFS(メディア、大きなファイル、vm)

XFSファイルシステムは縮小できないため、注意してください。また、オンラインルートボリュームの縮小はおそらくサポートされていません。

アップグレード ディスクをより大きなサイズに交換したい場合、いくつかのオプションがあります。最も簡単なのは、ドライブをペア以上で追加し、新しいRAIDアレイを現在のLVM VGに追加することです。

別のオプションは、現在のスペースの合計に> =である単一のドライブを追加することです。たとえば、RAID10に2つの100GBデバイスがある場合、新しい200GBデバイスを追加し、2つの古いデバイスを使用してミラーリングできます。これはエラーを起こしやすいですが、動作します。

必要に応じて、md#データを失うことなく、デバイスをLVM VGから削除できます。これは、使用されているすべてのLVMブロックをmd#デバイスから他のブロックにシフトするのに十分な空きLVMスペースがある場合に実行できます。LVMはLVに割り当てられていないスペースのみを使用できるため、空のファイルシステムは「空き」スペースとしてカウントされません。


1
/ bootにあるエキゾチックなファイルシステムの恐怖に納得しません。ext3とXFSは2009年にはもはやエキゾチックではありません。以前はliveCDにドライバーがパッケージ化されていなかったのが懸念事項でしたが、ほとんどすべては最近のものです。
ダンカーリー

@ Casey、Ext3ボリュームを「ライブ」で縮小できます。ただし、データを移動するための十分な空きスペースがあれば提供されます。はい、これは爪を噛むような経験ですが、私はそれをやったことがあり、宣伝どおりに機能します。パラメータには非常に注意してください。
エイブリーペイン

2

Linux Workstationを実行しています。私はext3ファイルシステムを使用しますが、サイズはディスクのサイズに多少依存しますが、大きなディスクのパーティションには余裕があります。これらはおおよそパーティションテーブルに表示される順序です。

  • / boot-100 MB
  • スワップスペース-2xRAM
  • / usr-10〜20 GB
  • /-5〜10 GB
  • / var-1-2 GB
  • / tmp-1-2 GB
  • / usr / local-10〜20 GB
  • / home-その他すべて。

大学の妻のワークステーションに2台の750 GBドライブがあり、上記に加えて、すべてが/ data / Nにマウントされたさまざまなドライブ全体で12個の〜100 GBパーティションを作成しました。Nは1〜12の数字です。彼女はこれらを使用して、さまざまな研究プロジェクトのデータを保持しています。


個人的には、/ var、/ usrを別のパーティションに分離する利点はありません。/ usr / localは、カスタムインストールされたソフトウェア(=パケット管理を介してインストールされていない)を持っている場合には良いアイデアかもしれませんが、言及された2つはかなり役に立たないです。また、スワップとしての2xRAMは不要です。システムがスワップを開始すると、すべてが完全に遅くなります。そのため、最初はこれを避けてください。一時的にディスクへのサスペンドを使用することがあるため、私は個人的にRamsize + Xでスワップパーティションを使用しています。
マーティン

2
@ Martin、Squidキャッシュとして動作するLinuxボックスでは、スプールディレクトリとログディレクトリを高速ディスクに配置する必要があり、通常、そのディスクの信頼性は必要ありません。RAID0(ストライプ)にスプールを(/ var)配置し、他のすべてを低速ドライブに残すことができます。
ゾレダチェ2009年

@Martin-そのとおりです。/usrを分割することはおそらく不要であり、私も常にそれを行うとは限りません。swap = 2xRAMは、256 MB以下のRAMでシステムを構成していた時代から残った古い習慣です。
ダゴリム2009年

1
実際、/ usrと/ varを分割すると、一方ではなく他方でジャーナリングを有効にできます。
スコット

1
また、/ varを別のパーティションに配置すると、/ varのみがログファイルでいっぱいになる可能性があります。そうしないと、システムがひどくなる可能性があります。
wzzrd

1

すべてのディスクでnoatimeを使用します(理由がない限り)tmpfsで/ tmpをマウントしますが、これはサーバー上ではあまり良くないかもしれませんが、別のパーティションであることを確認し、nodev、nosuid、noexec、noatimeをマウントします。私は常に/ bootにext2を使用しているため、fsを変更してgrubで起動する能力を台無しにすることを心配する必要はありません。他のすべてでext4、私は/ homeでjournal = dataを使用しますが、おそらくそれは少し遅くなります(deallocがないため)、journal = dataでデータを失ったことはなく、少し最新/最高です売春婦、時々私のシステムがロックし、ハードリセットする必要があります(kmsのようなものを試してバグを見つけたため)。


1
「nodiratime」も使用することを忘れないでください。そうしないと、vfs_cache_pressureに大量のiノード(および実際のディスクへの書き込み)をプッシュすることになります。
Gazzonyx

0

わあ、いい質問です。ヨンクスにとってこれに対する完璧な答えを求めてサーフィンをしてきました。

私は個人的には50Mb / boot〜8GBを持っていますが、残りは/ homeに行きます。代替ファイルシステムを調査する必要があります。現在はext3を使用していますが、XFSなどの他のファイルシステムの素晴らしいことを聞いています。

私は通常、/ tmpのファイルコンテナも純粋に作成するため、将来的にはより柔軟に対応できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.