ドライブ/パーティション文字がまだ使用されているのはなぜですか？

厳密に言えば、UUIDが解決されていません。別言します。

アドレス指定は非常に簡単です。ドライブ X セクター Y をお読みください。それ以外の場合。メモリアドレスZを読みます - それ以外の場合。アドレス指定は簡単で高速で、解釈の余地が多くなく、どこにでも存在します。

UUIDが解決されていません。代わりに検索して見つけ、時にはデバイスが表示されるのを待ち、ファイルシステムについて学ぶ（★）。また、端末の数によっては時間がかかる場合があります。見つかったら、通常のアドレス指定に戻ります。

GRUBでは（★★）と呼ばれ、searchGRUBに翼がある場合にのみ使用できます（検索はサポートするすべてのファイルシステムのモジュールなので、コアがロードされている場合にのみ使用できます）。 Linuxでは（たとえば）findfs、findfs は、システムのブロックデバイスからファイルシステムまたはパーティションを検索します。。

すべてのブロックデバイスを通過して待機状態から目覚め、データを読み込みます。 UUIDが一意でない場合（事故後など）、結果はまだランダムになる可能性がありますdd。変更しても何も起こりません。 UUID には構成エラーが発生しやすくなります。

通常、UUIDは優れており、もちろん、可能であればどこでも使用する必要があります。特に、Linuxのドライブ順序がランダムであるため、既存のアドレッシングは失敗する可能性がありますが、複雑さが単純なアドレッシングの意味を超えていることを理解する必要があります。特に、ブートローダの初期段階ではまだ選択肢ではないかもしれません。まず、問題を解決してから翼を育ててください。

ブートローダの場合、努力はまったく必要ないかもしれません（すべてのブートローダがGRUBなどの広範なファイルシステムをサポートしているわけではありません）。状況（BIOSで提供）が原因で「起動するディスク」が保証されている場合は、任意のhd0ドライブ順序の問題を排除できる場合は、潜在的に他の多くのパーティションのリストを見る必要はありません。 UUIDを検索します。

hd0,gpt2これが必要な構成であり、この方法でなければならず、この方法ではないと言えるほど構成に自信があれば、この方法を使用することに問題はありません。時には単純で簡単なアドレス指定が可能です。

（★）さっき説明しましたがここにタグを追加してください...

ラベルの普遍的な標準はなく、すべて手で編まれています。例をご覧ください。util-linuxでのスーパーブロック形式の実装。明日新しいファイルシステムを開発している場合は、ラベルがあってもサポートが追加されるまで表示されません。

...UUIDも同様です。

（★★）実際にはGRUBにはオプションがsearchあります--hintが…今はソースコードを確認せず、マニュアルに文書化もしていませんが、そのようなオプションは意味があり、両方の利点を提供します。プロンプトがsearch教えてください。まず、パーティションを確認してください、UUIDが期待どおりに一致した場合、デバイスを識別します。最小限の努力、一致するものがない場合は、検索全体に戻り、操作を続行します。

さらに、以前に検出されたUUIDはキャッシュされる傾向があるため、すべてのデバイスを引き続き検索する必要はありません。探しているUUIDがキャッシュに格納され、実際にどこかに存在する限り、この方法もうまく機能します。まず。