カーネル空間の観点から、ファイルシステムUUIDはどのように機能しますか（そして、一意でない場合はLinuxボックスはどうなりますか？）

最後に、これが私が答えを探したい質問だと思います。ルートファイルシステムに固有のUUIDがない場合、Linuxシステムはクラッシュしますか？しかし、読んでください。この質問は、誤った構成による影響ではなく、原因に関する洞察を得ることに関するものです。

ルートファイルシステム全体（UUIDを含む）を同じサイズの別々のパーティションに複製できることを考えると。ソースとレプリカの両方で、inodeはディスク上の同じファイルと同じブロックのコピー（パーティション）を指しているため、問題が発生し始めることに気付くことはありません。

しかし、その場合は、その理由や問題の性格が何であるかを知りたいと思います。できる予想されます。ファイルシステムのUUIDがあなたの人生をより簡単にする方法、どのように機能するのか、どのように機能するのかについて多くの記事がありますudev。/devまた、UUIDがLinuxシステム内で一意でなければならないという意見もあります。 UUIDはユーザースペースの観点からかなりよく文書化されていると思います。カーネル空間の視点を理解したいより良いもの。

たとえば、一部のブロックはあるパーティションで読み書きすることができますが、他のブロックは別のパーティションで読み書きするパーティションのブレーンの種類が発生する可能性がありますか?カーネルをロックできますか？他のデバイスの取り付けおよび/または取り外しに問題がありますか？おそらくもう1つ重要なのは、マルチパスがどのように適用されるか、非常に特殊な冗長UUIDケースを管理できることです。

実際の質問に戻って：カーネルは実際にこれらのUUIDを内部的にどのように活用しますか？ UUIDでファイルシステムをマウントしたりmount、dfまたは出力を確認したりする/proc/mountsと、マウントコマンドを実行するために使用するUUIDは表示されず、常にデバイスノードが表示されます/dev。 UUID-デバイスマッピングのためのユーザー空間インターフェイスはありますか（デバイス-UUIDと同じである必要はありません）。カーネルはアクセスするブロックデバイスをどのように決定しますか？これは時間が経つにつれてどのくらい自発的に変化しますか(おそらく特定の出来事のため)?独自のUUIDという単純な規則に従わないと、私のマシン/ファイルシステムに何が起こりますか？

たぶん私の答えはhttps://www.kernel.org/doc/しかし、私が正確に何を探しているのかわからないときは、少し負担になります。サイトへのディープリンクも歓迎します。