為什麼仍然使用驅動器/分區號？
很多時候，尤其是在使用引導載入程序時，我會看到使用的數字驅動器和分區號。例如，在我的
/boot/grub/grub.cfgI seeset root='hd0,gpt2'中，我的 UEFI 引導條目經常引用驅動器/分區號，並且它似乎出現在幾乎所有涉及引導載入程序的環境中。現在我們有了 UUID 和 PARTUUID，以這種方式定址分區似乎非常不穩定（afaik，不能保證驅動器總是以相同的順序安裝，使用者可以移動驅動器插入其主機板的順序等）
因此，我的問題是雙重的：
- 這種定址方案是否像我上面概述的那樣不穩定？我是否遺漏了標準中的某些內容，這意味著該方案比我預期的要可靠得多，或者由於您的驅動器只是在不同的順序或將它們插入主機板上的不同插槽？
- 如果上述問題的答案是肯定的，那麼為什麼還要繼續使用這種定址方案？對所有事情都使用 UUID 或 PARTUUID 會不會更加穩定和一致？
普通編號方案實際上並沒有在最近的系統中使用（“最近的”是 Ubuntu 9 及更高版本，其他發行版可能也適應了那個時代）。
您正確地觀察到根分區是使用普通編號方案設置的。但這只是預設或備用設置，通常會被下一個命令覆蓋，例如：
search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a這會根據文件系統的 UUID 選擇根分區。
在實踐中，普通編號方案通常是穩定的（只要沒有硬體更改）。我觀察到的唯一一個不可預測編號的實例是具有許多 USB 驅動器的系統，這些驅動器基於先到先服務模式進行列舉，然後模擬為 IDE 驅動器。這些過程中沒有一個本質上是混亂的，所以我假設特定係統 BIOS 實現中存在問題。
注意：這裡的“根分區”是指啟動的分區，它可能與包含“root aka./file system”的分區不同。
嚴格來說，UUID 根本不是定址。
定址非常非常簡單：讀取驅動器 X 扇區 Y - 否則。讀取記憶體地址 Z - 否則。定址簡單、快速，沒有太多解釋空間，而且無處不在。
UUID 沒有定址。相反，它是搜尋、查找、有時等待設備出現，以及了解文件系統(★)。根據設備的數量，可能需要很長時間。一旦找到，就回到正常定址。
在 GRUB 中，這稱為
search(★★)，它僅在 GRUB 已經長出翅膀時才可用（搜尋是一個模組，它支持的每個文件系統也是一個模組，因此只有在載入核心後才可用）。在 Linux 中，它（例如）被稱為findfsfindfs將搜尋系統中的塊設備以查找文件系統或分區。它遍歷所有塊設備，將它們從待機狀態喚醒，讀取數據，如果 UUID 不是應有的唯一性（在
dd事故等之後），結果甚至可能仍然是隨機的，或者如果 UUID 改變了，您將得不到任何結果 - UUID 也容易出現配置錯誤。一般來說，UUID 非常棒，當然，如果可用的話，你應該在任何地方使用它們，尤其是當傳統定址注定會失敗時，因為 Linux 中的驅動器順序是隨機的；但要明白，複雜性超出了簡單定址的目的。尤其是在引導載入程序的早期階段，它可能還不是一個選擇。先解決，後長翅膀。
對於引導載入程序，可能根本沒有必要付出努力（並非每個引導載入程序都支持廣泛的文件系統，如 GRUB）。如果
hd0由於情況（BIOS 提供）而保證是“我們啟動的磁碟”，因此如果您可以排除隨機驅動器順序問題，則可能無需查看潛在的大量其他分區列表搜尋 UUID。如果您對自己的配置有足夠的信心，可以說這
hd0,gpt2是您想要的，而且必須是，否則就不可能，那麼這樣使用它就沒有錯。有時，簡單明了的定址就可以了。(★) 我之前在這里為 LABEL解釋過這個……
標籤沒有通用標準，都是手工編織的，例如在 util-linux 中查看 superblocks 格式的實現。如果你明天發明一個新的文件系統，即使它有標籤，在添加支持之前它也不會出現。
…對於 UUID 來說也差不多。
(★★) 實際上，GRUB
search有一個--hint選項，而且…現在我還沒有檢查原始碼，甚至在他們的手冊中也沒有記錄，但是這樣的選項可以為您提供兩全其美的選擇：提示應該告訴search首先檢查該分區，如果 UUID 與預期匹配，它會以最小的努力辨識設備，如果不匹配，它仍會回退到完整的搜尋以保持事情以某種方式工作.除此之外，以前發現的 UUID 往往會被記憶體，因此它不必一遍又一遍地遍歷所有設備 - 這也很有效，前提是您要查找的 UUID 確實存在於某個地方首先將其放入記憶體中。