☰

GPT か MBR か?

tag-icon • tag-icon linux lvm gpt
GPT か MBR か?

私は Linux 初心者です。次の手順に従って、2TB のハード ドライブに Squeeze をインストールする予定です。

  • / - 10GB
  • スワップ
  • 残りのスペースには/homeが含まれ、約1.9TBになると思います。後で古い1TBドライブを追加するためにlvmとして使用してみます。

私の質問は、GPTを使用する必要がありますか？それともMBRで十分でしょうか？

GPT が必要な場合、このスキームは適切でしょうか?

  • /boot - 150MB
  • / - 10GB
  • スワップ
  • /home (残りのスペースがある lvm)

ちなみにマザーボードはASRock G41ですが、EFIをサポートしていないと思います。

答え1

GPT か MBR か?

@mgorven が言ったように、どちらも 2TB で動作します。私は 2T ディスクに数十の MBR ディスク ラベルを展開しましたが、問題なく動作しました。これは本当にあなたの選択です。私は今のところ MBR を好んで使用していますが、これはすぐに変わります。

UEFI と GPT

GPTディスクラベルをディスクに書き込むのにUEFIは必要ありません。また、賢い人なら、GPTディスクラベル付きのディスクをUEFI以外のROMから起動することも可能です（ただし、私は試していません）。GPTに関するWikipediaの記事これについては間接的な情報があります。

ゾーン

これは多くの人に無視されていますが、する重要な役割を果たします。しかも、その役割は潜在的に非常に大きいものです。これは非回転式大容量ストレージでは問題になりませんが、ディスクでは長年問題となってきました。幾何学と物理学に関係する理由により、ディスクのスループットはディスクの先頭付近で最も高くなります。スループットはゾーンに分割され、あるゾーンから別のゾーンに移動するにつれて速度が低下します。これは、最も速度を必要とするパーティションをディスクの先頭付近に保つ必要があることを意味します。この違いは、ディスクの最初の数ギガバイトで非常に顕著になります。

Unix のディスク パーティション分割

多数のファイルシステムが必要になる理由としては、次のようなものがあります:

  • 全ての卵を一つのバスケットに入れるわけではありません。ファイルシステムの1つが破損した場合、バックアップから復元すれば、通常の状態に戻ります。全てファイルシステムが破損すると、ダウンタイムやトラブルが増え、イライラも増します。
  • 各ファイルシステムは、パフォーマンス上の理由から、別々に調整できます。MailDir を保存するファイルシステムでは、いくつかのディレクトリに数十万の小さなファイルが存在する可能性があります。ビデオ ファイルを保持するファイルシステムには、数十の巨大なファイルがあります。最適化できます。
  • ファイルシステム内のスペースを予約して、他のユーザーが使用できない場合に特定のユーザーが使用できるようにします。通常、ルートはファイルシステムのスペースの 5% を予約します。複数のファイルシステムがある場合は、これを調整できます (たとえば、メール スプール ファイルシステムには、メール ユーザーにスペースを割り当てることができます)。
  • バックアップ ポリシーを簡素化して、1 つのファイル システムを 1 つのバックアップ メディアに適合させます。これは、バックアップ ポリシーとソフトウェアによって異なります。
  • たとえば、 の別々のファイルシステムを使用すると、/home1 台のコンピューターに複数の *nix オペレーティングシステムをインストールして、それらの間でファイルを共有することができ、面倒な手間がかかりません。
  • システムの制限を解決できます。たとえば、過去には、一部のディスクはディスクの先頭から遠すぎるディスク ブロックから起動できなかったため、/bootディスクの最初のブロックを占有するのに十分な小ささのファイル システムを作成しました。
  • 速度を最適化できます。重要なファイルシステムを最速のディスク ゾーンに配置します。
  • 起動速度: fsck20G のファイルシステムを実行する方が、fsck1900G のファイルシステムを実行するよりも高速です。チェック期間を巧みに選択することで、実行を分散させることができますfsck。

以下の理由により、ファイルシステムをあまり多くしたくない場合があります。

  • ディスク領域を量子化しています。ディスクに 100G を保存する必要がある場合、合計で 200G の空き領域があるのに、十分な空きディスク領域を持つパーティションが 1 つもないことがあります。
  • ディスク ラベルの機能によって制限されます。多くの Unix では、ディスク ラベルに 8 つのパーティション/スライスしか収まらず、そのうちの 1 つは予約されています。MBR ではこの点であまり制限がなく、GPT では 128 個のパーティションが許可されますが、これは必要以上に多い数です。
  • ファイルシステムが多すぎると、作成や管理が面倒になります。
  • ファイルストレージのニーズはそれほど多様ではありません。

ファイルシステムスキーム

誰もが自分の好みを持っています。以前はスプレッドシートを使って計算していましたが、たいていは紙と古いタイプの筆記具 (なんとも古風な) を使っています。満足するまで何度も繰り返して、パーティション スキームをコンピューターにコミットします。この方法の方が高速です。ほとんどの Debian ベースのサーバーでは、次のファイル システムを分離しています。

  • /（根）
  • /boot
  • /usr
  • /var
  • /usr/local
  • /tmp
  • /home
  • 予備ファイルシステム

追加のニーズには、写真用の別個のパーティション (バックアップ ポリシーは異なります)、ビデオ用の別個のパーティションなど、別のファイル システムが必要です。メール サーバーには、電子メール用の別個のパーティションが必要です。データベース サーバーには、データ ストアとディスク上の一貫性のあるデータベース バックアップ ファイル用の別個のパーティションが必要です。ただし、基本スキームはほぼ常にこれです。

また、ディスクの最後に予備のファイルシステムを保持しています。mkfsこれをスクラッチ スペースとして使用し、/disk1(作業上の慣例) または/disk/tmp(私の慣例) でマウントすることがよくあります。このファイルシステムは、新しいニーズが見つかった場合 (削除して別のファイルシステムを拡張するか、単に再利用することができます)、または大量のスクラッチ スペースが必要な場合に役立ちます。

サイズ

コンピュータの用途によって大きく異なります。多くの場合、非常に小さなサイズでも問題ありません。私の提案は、LVM (続きを読む) を使用して、、およびにそれぞれ 10G を割り当てることです/usr(/var独自/usr/localのソフトウェアをコンパイルしてインストールする予定がない場合は、より小さくします)。私は/tmp1～2G 程度の小さめにしています。ルート ファイルシステムに大きなファイルシステムをすべて配置しなければ、これも小さめにできます。私の現在のボックスには 2G のパーティションがあり、十分なスペースが残っています。/bootカーネル開発者でない場合は、ファイルシステムを非常に小さくしたり、完全に省略したりできます。最近のコンピュータと最新バージョンの GRUB では、これを問題なく処理できます。必要な場合は、約 200～300 MB で十分です。

ライトVM

私は長い間、LVM 以外のシステムを導入していません。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 ディスクの場合、/homeパーティションは 2000 - 8 - 2 - 10 - 10 - 10 - 2 - 30 = 1928G になります。

予備の 30G パーティションは、他のボリュームにさらにスペースが必要な場合に便利です。LVM ボリューム (および ext{2,3,4} ファイルシステム) のサイズを変更するのは簡単です。

別個の はなく/boot、すべてのブートストラップインフラストラクチャ（カーネルとinitrd）が内部LVM。これは一部の人にとっては不安ですが、私はこれまで問題に遭遇したことはありません。GRUB は LVM 物理ボリュームの内部を問題なく見ることができます。不安な場合は、/boot約 200M の別の領域を作成してください。パーティション 2 (LVM PV パーティション 3 を作成) またはパーティション 1 (他の 2 つを押し下げる) のいずれかにしてください。

答え2

MBR は 2TB ドライブでは問題なく動作しますが、それ以上の容量のドライブでは動作しません。ただし、使用するすべてのオペレーティング システムが MBR をサポートしている限り、MBR を使用するか GPT を使用するかは問題ではありません。GPT ドライブから起動するために、BIOS が EFI をサポートする必要はありません。

MBR と GPT のどちらを使用するかに関係なく、スペースの管理には LVM を使用することをお勧めします。これは、LVM の方がはるかに柔軟性が高く、後の段階で変更が容易だからです。

答え3

少し考えすぎだと思います。GPT と MBR のどちらが重要になるかは、複数のオペレーティング システムをインストールする場合や、ドライブを別のコンピューターに移動する場合にのみ重要です。MBR で済むのであれば、MBR を使い続けるのがよいでしょう。特に、LVM (MBR にはない多くの機能を使用できます) を使用している場合はなおさらです。

パーティション サイズに関しては、次のような経験則が役立ちます。

  • パーティションが小さいと、実際にどれだけ使用するか事前にわからないため、面倒な場合があります。
  • 大きなパーティションは、構築とチェックに長い時間がかかるため、面倒な場合があります。また、ファイルシステムの「消耗」は、使用状況に応じて蓄積される傾向があります。すべてを 1 つのパーティションに配置すると、この蓄積が速くなります。それが何の価値があるかはわかりませんが。

答え4

ファイルシステムが小さすぎることが判明すると、通常は問題になります。10 GB はバイナリとログ ファイルで簡単にいっぱいになります。ディスク領域は豊富にあるのに、なぜ領域を節約しようと必死になっているのでしょうか。しばらくすると後悔することになります。ディスク領域を一度に割り当てるのではなく、必要に応じてファイルシステムを移動できるように領域を残しておいてください。ファイルシステムを拡張するのは簡単ですが、縮小するのは簡単ではありません。LVM2 で何ができるかを確認してください。http://tldp.org/HOWTO/LVM-HOWTO/index.html 今後何年も自分を縛り付けるような悪い決断をしないでください。

関連情報