/usr/binと/usr/sbinを/bin(GNU/Linux)にマージ

/代わりに/usrにコンテンツをマージする理由は次のとおりです。/usr マージケース:

誤解＃11：/を/usrにマージするよりも/usrを/にマージする方が合理的です。

事実：これにより、ベンダーが提供するOSリソースとシステム固有のリソースの分離がより深刻になり、OSスナップショットとネットワーク/コンテナの共有がより困難で非原子的になり、大規模な新しいディレクトリによってルートファイルシステムが複雑になります。

あなたは正しいです。 Fedoraはこの点ではアバンギャルドです。無料デスクトップウェブサイトその後、独立組織が汎Linuxを奨励するためにプロジェクトを開始しました。

~によるとこれ、マージはSolaris（「主な商用Unixの実装」）で始まるパターンに従います。興味深いことに、raw Unixを使用していた/binので、分割を削除することは、おそらく/usrシンボリックリンクにディレクトリを作成することを意味したでしょう。その逆ではありません。

ただし、このオプションを念頭に置いて最上位レベルをリンクする方がより直接的で明確です。

/sbinと/usr/sbinは、歴史的に静的にリンクされたバイナリが保存される場所です。 / sbinは初期化レベル1（シングルユーザーモード）に必要な管理レベルコマンドに使用され、/ usr / sbinは初期化レベル3（フルネットワーキング、リモートログイン有効、NFS有効）に必要なより一般的な管理コマンドに使用されます。 。残念ながら、Linuxはもはやこのモデルを採用しません。

システムエンジニアとして、私はこの傾向が残念だと思います。たとえば、フラッシュメモリはアクセス速度が非常に高速ですが、高価で（回転ディスクメディアよりGBあたり3倍高価です）、デバイスが正常に動作しない前にメモリビットに静電気が蓄積するという問題があります。大量のデータしか書き込めません。使用できません（ソフトエラーは最初にデバイスファームウェアによって修正され、次にハードエラーが修正され、この時点でデバイスは読み取り専用としてマークされます）。

だから私たちはまだ「高速で高価なメモリ」と「ゆっくりと安いメモリ」を持っているのです。

Raspberry Piでも、私は小さな2.5インチディスク（ノートブックサイズ）をUSB 3.0ポートに接続し、必要なすべてのブート関連エントリを/ binに入れます。します。 /tmpおよび/var/tmp、特に/var/logおよび/var/cacheなどの多くの書き込みアクティビティ... より安価で耐久性のある1TB 2.5"ディスクにこれらのサブツリーが連続的に書き込まれるためです。設定時には、通常、書き込みが高いクォンタムツリーを中間書き込みクォンタムツリーから分離し、書き込みが低いクォンタムツリーを/var/logとは別にユーザーアカウントファイルシステム（/homeなど）に分割するために、いくつかのファイルシステムを正確に作成します。 。

/opt は /usr/_opt へのポインタにすることができます。 （私はシンボリックリンクのソースを表すためにプレフィックスとプレフィックス_文字をシンボリックリンクターゲットとして使用します。したがって、/optは/usr/_optを指すシンボリックリンクになります。/tmpは/mnt /highwritesになります。/_tmpそして/ var / tmpは/ mnt / highwrites / _var_tmpへのシンボリックリンクになるので、どんな "tmp"ディレクトリにもっとスペースが必要かを推測する必要はありません。が発生すると、他のすべてのファイルシステムから安全に分離されます。

/ usrと/をマージすることは常に愚かな計画であり、Sun Microsystemsとその歴史を尊重するだけにSunがこのような狂気を始めたかどうかはまったく気にしません。最も重要なインストールされたソーラーシステムは、毎日使用される適切なシステムバックアップリソースを保持するのに十分に高価で重要です。一般的な Linux システムには、特に家庭および小規模企業のユーザーにはそのような資本投資はありません。

したがって、デフォルトの構成ではセキュリティの観点からエラーが発生し、ほとんどのファイルシステムへの書き込みを分離するために、独自のファイルシステムで最もアクティビティの高いディレクトリを分離する必要があります。これにより、ファイルシステム全体を統合するのではなく、データの損失を最小限に抑え、問題を最も価値のあるアイテムに伝播します。ファイル（1.ユーザーデータ、システムの起動と破損の評価と回復に必要な実行可能ファイルとディレクトリ（fsck、ダンプと復元の種類プログラム、mkfs、mkswap、およびいくつかのファイル）grepなどのその他の便利なプログラム、そしてもちろんすべてのハードウェアといくつかの仮想（例：RAID）デバイスドライバ）

Userland アプリケーションは、伝統的に /bin および /sbin にある「システム必須項目」よりはるかに頻繁にアップグレードやバグ修正を受ける傾向があります。ファイルシステムを小さく保ち、書き込みを行うと、破損の可能性がほとんど減少しません。伝統的に、/ usrの内容が破損しているかどうかはあまり気にしませんが、mountとfsckが破損したファイルシステムにあるかどうかは確かに気になります。

単一のストレージ技術（単一の1TBハードドライブなど）を使用している場合でも、ルートパーティションをできるだけ小さく保つ必要があるという単純な理由から、/ usrを別のパーティションに配置する方が合理的です。できるだけ書いてください。

「できるだけ早くインストールする」に関しては、ほとんどのブート構成では、カーネルがロードされると/ファイルシステムがfsckedされてマウントされます。 fstabは起動時にインストールで構成されるため、「より高速な可用性」は問題になりません。さらに、連続してfsckする10個の小さなファイルシステムは、単一のファイルシステムよりも高速にfsckできます。読み書きヘッドの前後ヘッドの移動が狭い範囲内に維持され、検索期間が短くなり、2番目に次のヘッドを見つけるためのヘッドがやや長くなるためです。単一ディスク全体をカバーするファイルシステムは、内部トラックから遠い外部トラックに数千回移動できます。

単一のディスクを複数のファイルシステムに分割することの唯一の欠点は、ほとんどの書き込み操作が中間の一連のパーティションではなく、最初と最後のパーティションで実行され、ディスクが1つのAファイルシステムで変更されることです。あるパーティションのファイルが別のパーティションのファイルシステムに移動された場合は、すべて統合された単一のファイルシステムにある場合よりも多くの空のブロックを通過する必要があります。

全体として、単一ファイルシステムの利点は、単一の記憶装置を複数のファイルシステムに分割する利点よりも依然として重要である。信頼性とデータセキュリティの観点からは、マルチファイルシステム（それぞれ独自のデバイスにあります）が好ましい（最も費用がかかる）アプローチです。パラレルSCSIが普遍化されたとき、中古SCSIディスクを安く購入しようとしました。 1 つは / 用、1 つは /usr 用、1 つは /home 用の最小 (通常最も古いもの) /tmp、/var/tmp、/var/log。このデバイスは通常、最も小さく失敗する可能性が高く、ファイルの値は比較的低いです（ユーザーが指定しない限り、プログラムは結果を/ tmpに保存しません... /tmpおよび/var/tmpsは使い捨てデータは「スクラッチ」領域であり、単一の/ tmpディレクトリはNFSを介して複数のホストで共有できます。

Poetteringは実際にLinuxをMS-WINTENDOに簡素化しようとしました。