GPTまたはMBR？

@mgorvenが言ったように、両方とも2TBで実行できます。私は2Tディスクに何十ものMBRディスクラベルを配布しましたが、それはうまくいきます。それは本当にあなたの選択です。今はMBRが最初の選択ですが、すぐに変わる予定です。

UEFIとGPT

ディスクにGPTディスクラベルを書き込むためにUEFIが必要なく、十分にスマートな場合は、UEFIではなくROMからGPTディスクラベルを使用してディスクを起動することを想像できます。まだこれを行っていません）。これGPTに関するWikipediaの記事これに関する間接的な情報があります。

エリア

これはしばしば見落とされますが、する変更を作成し、おそらく大きな変更をもたらすことができます。これは回転しない大容量ストレージの問題ではありませんが、長年のディスクの問題でした。幾何学と物理学に関連する理由のために、ディスクスループットはディスクの始めの近くで最も高い。スループットは地域別に分類され、ある地域から別の地域に移動すると速度が低下します。これは、最速の速度を必要とするパーティションをディスクの先頭の近くに維持する必要があることを意味します。この違いは、ディスクの最初の数ギガバイトで非常に顕著です。

Unixディスクパーティション

次の理由で、多くのファイルシステムが欲しいです。

• すべての卵を1つのバスケットに入れません。ファイルシステムが破損している場合、バックアップから復元すると寿命が正常に戻ります。もしみんなファイルシステムが破損し、ダウンタイムが長くなり、問題が増え、迷惑が多くなります。
• パフォーマンス上の理由から、各ファイルシステムを異なる方法で調整できます。 MailDir を保存するファイルシステムには、複数のディレクトリに数十万の小さなファイルを含めることができます。ビデオファイルが保存されるファイルシステムには、数十の大容量ファイルがあります。最適化できます。
• ファイルシステムのスペースを予約し、他のユーザーが使用できない場合は、特定のユーザーがそれを使用できるようにすることができます。 rootユーザーは通常、ファイルシステムの5％を予約します。複数のファイルシステムの場合は、これを調整できます。たとえば、メールプールファイルシステムはメールユーザーにスペースを割り当てることができます。
• 1つのファイルシステムが1つのバックアップメディアに合うようにバックアップ戦略を簡素化しています。これはバックアップ戦略とソフトウェアによって異なります。
• たとえば、別々のファイルシステムを使用すると、単一のコンピュータに/home複数の* nixオペレーティングシステムを保持し、混乱なしにそれらの間でファイルを共有できます。
• システムの制限を解決できます。たとえば、過去には、ディスクの先頭から遠すぎるディスクブロックからブートできなかったため、ディスクの/boot最初のブロックを占めるのに十分な小さなファイルシステムを作成しました。
• 速度を最適化できます。重要なファイルシステムをディスクの最速領域に配置します。
• 起動速度：20Gファイルシステムはfsck1900Gファイルシステムより高速です。チェック期間を賢く選択すると、ジョブを分散fsckさせることができます。fsck

次のような理由で、あまりにも多くのファイルシステムが欲しくないでしょう。

• ディスク容量を数量化しています。ディスクに100Gを保存する必要がある場合は、合計200Gの空き容量がありますが、単一のパーティションに十分な空きディスク容量がないことがわかります。
• ディスクラベルの機能によって制限されます。多くのUnicesはディスクラベルに8つのパーティション/スライスしか保持できず、そのうちの1つは予約されています。 MBRはこれに関してあまり制限されていませんが、GPTは必要以上に128のパーティションを許可します。
• あまりにも多くのファイルシステムを作成して管理するのは面倒です。
• ファイルの保存要件はあまり変わりません。

ファイルシステムソリューション

誰もが自分の好きなものがあります。私はこれを計算するためにスプレッドシートを使用しましたが、紙や昔ながらの手書きツールを使用することがよくあります（いくら奇妙ですか？）。満足するまで何度も繰り返し、パーティションスキームをコンピュータに送信します。これはより速いです。ほとんどのDebianベースのサーバーは、次のファイルシステムを分離します。

• /(根)
• /boot
• /usr
• /var
• /usr/local
• /tmp
• /home
• 代替ファイルシステム

他の人は、写真用の別々のパーティション（別のバックアップ戦略を使用）、ビデオ用の別々のパーティションなどの他の別々のファイルシステムをインポートする必要があります。メールサーバーは、電子メール用の別々のパーティションを提供します。データベースサーバーは、データストアやディスク上の一貫したデータベースバックアップファイルなどのために別々のパーティションを取得します。しかし、基本的な計画はほぼ常にこのようです。

また、ディスクの最後にバックアップファイルシステムを保持します。私は主に（作業コンベンション）または（私のコンベンション）mkfsの下に設置してスクラッチスペースとして使用しています。このファイルシステムは、新しい要件を見つけたり（削除したり、他のファイルシステムを拡張したり、目的を変更したりすることができる）、スクラッチスペースがたくさん必要な場合に便利です。/disk1/disk/tmp

サイジング

コンピュータの用途によって多くが異なります。多くの場合、非常に小さいサイズを使用できます。私の提案はLVMを使用し（続きを読む）、/usrそれぞれに10Gを割り当てることです（または独自のソフトウェアをコンパイルしてインストールする予定がない場合は小さいサイズ）。私は1〜2G程度に小さく保ちます。ルートファイルシステムに大きなファイルシステムがすべて含まれていない場合は、小さい方が良いかもしれません。現在のボックスには2Gパーティションがあり、まだ十分なスペースがあります。カーネル開発者ではないか、それについて全く考えていない場合、ファイルシステムは非常に小さいかもしれません。最新のコンピュータと最新のGRUBバージョンはこれを非常にうまく処理します。必要に応じて200-300MB程度が適しています。/var/usr/local/tmp/boot

左心室容積

長い間、LVM以外のシステムを展開していません。あなたが得る柔軟性は短い学習期間と同じくらい価値があります。 LVMを使用すると、心を変える余地が増え、ファイルシステムも一緒に成長することができます。本当におすすめです。

例のシナリオ

• パーティション1：スワップスペース（ディスクの始まり）
• パーティション2：「fs」または別の名前のボリュームグループを持つLVM物理ボリューム。
  • 容量fs-root：〜2G。
  • ボリュームfs-usr：〜10G。
  • ボリュームfs-var：〜10G。
  • 容量fs-local（略語/usr/local）：〜5〜10G。
  • 容量fs-tmp：〜2G。
  • ボリュームfs-home：残りのスペースから約30Gを引いたスペースです。
  • 容量fs-spare：残りスペース：〜30G。

8Gのスワップスペースを持つ2Tディスクでは、パーティションは/home2000 - 8 - 2 - 10 - 10 - 10 - 2 - 30 = 1928Gです。

1 つ以上の追加ボリュームに対応するためにさらに多くのスペースが必要な場合は、スペア 30G パーティションが便利です。 LVMボリューム（およびext {2,3,4}ファイルシステム）のサイズ変更は非常に簡単です。

独立したフルブートインフラ/bootストラクチャ（カーネルとinitrd~へLVMこれは何人かの人々を怒らせるが、私は決して問題を経験したことがない。 GRUBはLVM物理ボリュームの内部をよく示しています。気になる場合は、/boot200M程度のスペースを別に確保しておいてください。パーティション2（LVM PVパーティションを3に設定）またはパーティション1（他の2つのパーティションを下にプッシュ）に設定します。