これファイルシステム階層標準（FHS）はLinuxのインストール時にルートファイルツリーの公式エンコーディングで、以前のバージョンのUnixとPOSIXから継承され、その後調整されました。さまざまな歴史的規則の違いに基づいて、使い慣れた、、、、など/homeの/etc正確/usrな/var使用法を標準化し、追加または追加できない可能性があるアプリケーション固有およびサイト固有のファイル名の問題を解決します。
歴史的に、デフォルトのLinuxインストールはツリー全体を単一のファイルシステムに配置しましたが、いくつかのバリエーションではおそらくバックアップと移行を/home容易にするために別々のパーティションを使用していました。
最近、BTRFS採用が増加するにつれて、単一のパーティションでさまざまなサブボリュームをホストできます。サブボリュームはスナップショットとしてキャプチャすることができ、空き領域割り当てを必要としないので魅力的です。
FSHのノードへのサブボリュームマッピングは非常に多様であるようです。スナップショットと関連問題に関してシステム上のファイルを最適に管理できるようにするには、問題の合理的な標準とポリシーを尊重することが重要です。
以下はいくつかの観察事項です。
- ダーバンツリー全体をルートの単一のサブボリュームに配置するようです。
- Ubuntu1つのサブボリュームがに割り当てられ
/home、別のサブボリュームが残りのルートツリーに割り当てられているようです。 - アーキテクチャLinux
/var/log/var/cacheDebian で採用されている分離は、別々のサブボリュームに置いて展開されたようです。 - SUSEを開く
/var、、、、およびそれぞれに1つのサブボリュームがあるだけでなく、残りのルートツリーに1つ、インストールされている各グルーブアーキテクチャに1つあります。/home/root/usr/local/opt/srv
さまざまな設計上の考慮事項を解決し、さまざまなオペレーティングシステムで取られるアプローチを統合する標準はありますか？スナップショット戦略に基づいてさまざまなファイルツリーノードの機能を調整する方法について合意がありますか？
答え1
いいえ、まだそのような標準が出ていません。
答え2
FWIW CISセキュリティ標準は、独自のファイルシステム保有の利点を明確に示しています。 cisecurity.org/cis-benchmarks
@steve、質問のトピックに関するあなたのコメントを理解していません。
CIS（またはUSG STIG）ベンチマークヒントFHSリンクに記載されているように、Linuxファイルシステムの上にある他の多くのフォルダのいくつかに対して別々/homeの/varパーティションを作成するセキュリティを装った標準です。/usr私がおなじみのベンチマークには、いくつかのベンチマークバージョンから多くのフォルダが削除されているので、別のパーティションで使用する必要があります。/homeそれ以外/varの場合は、安全な検索：rolleyes：です。/var/log/audit彼ら議論する声明はただ 異なるパスに別々のファイルシステムを使用すると、ファイルシステム全体またはエラーが発生したファイルシステムによって引き起こされるエラーからシステムを保護できます。 この論理のすべての抜け穴を見つけることは読者の皆さんに任せます。
さまざまなディレクトリを別々のパーティションとしてマウントすると、管理者はこれらのパーティションをマウントしたり、クォータ対応ファイルシステムを使用したりできます。noexecこれはnosuidいくつかのセキュリティ上の利点を提供しますが、通常は管理組織に役立ちます。しかし、このようなタスクを実行するための「標準」はありません。 Debian、Arch、OpenSUSEに言及すると、彼らはすべて異なるパーティションスキームを持っています...私の考えでは、彼らはCISベンチマーク、「セキュリティ」思考方法、そして暖かい曖昧さの影響を受けます。販売ポイント。
「標準」は、現在の環境の要件を満たすのに適していると考えられるパーティションスキームに対するLinux管理者の推奨事項でなければなりません。どのフォルダが別々のパーティションにあるのか、どのフォルダが別のパーティションにあってはならないのかを一日中議論することができます。これはすべて正当な理由があるため、この特定の作業の標準が実際には発生しない理由です。
私はこれが特にBTRFSにとって良い質問だと思います。 BTRFSがスナップショットやその他の機能のサブボリュームとパーティションに興味を持っているかどうかを調べます（そうではありませんが、正直に言うことはできません）。