#本來device被對應成UUID，那麼如何取得UUID呢？
proc /proc proc defaults 0 0
# Entry for /dev/sda2 :
UUID=0e4aa4fb-46cf-4b5e-9dad-cc9e7eeda693 / reiserfs defaults 0 1
# Entry for /dev/sda1 :
UUID=a56f8c86-92b7-4de8-a9dd-f959bacce64e /boot reiserfs notail 0 2
# Entry for /dev/sda3 :
UUID=abd8bfbe-006c-44f9-aa91-720bc9b4ab5c /home reiserfs defaults 0 2
# Entry for /dev/sda4 :
UUID=c26ad5ec-652d-48aa-a33c-bcafde4451f7 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
ls -l /dev/disk/by-uuid
接著可能下一個疑問就是，為何要用UUID，請參考
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/zh_tw/admin-guide/s1-storage-rhlspec.html
底下是部份節錄，如果你使用隨身硬碟，裡面裝的是過去window$的分割區，你會發現，你可能會有auto-mount順序的問題，如果改寫fstab，然後用UUID
不過話說回來，人們對於使用UUID的褒貶不一，有人說以前的/dev/sda之類的方式還很清楚，改成UUID這一串長長的字串，反而不容易辨識由於新增或移除儲存裝置，會導致現有裝置的檔案名稱跟著變動，所以當系統重開機之後，可能會面臨儲存裝置無法存取的命運。底下一連串動作，就有可能導致這樣的結果：
系統管理者加裝一張 SCSI 控制卡，並在上面接了兩顆新的硬碟（現有的 SCSI 卡已經接滿了）。
舊的 SCSI 硬碟（包括卡上接的第一顆硬碟 /dev/sda）不做任何更動。
重開機
因為新 SCSI 介面卡上的第一顆硬碟叫做 /dev/sda，所以先前叫做 /dev/sda 的 SCSI 硬碟得有個新名字
理論上，這聽起來是個大問題；不過事實上不會那麼嚴重。第一，這種硬體變動很少出現。第二，系統管理者多半會停機一陣子，好更動系統；停機時間需要事先仔細規劃，以免超出預計的時間，影響正常運作。這事先規劃的好處，則是讓管理者評估任何裝置名稱改變，可能帶來的問題。
然而，有些企業與系統設定就可能遇到這麻煩。常常更動儲存環境，以符合某些需求的公司，有時候就不容許任何停機時間。像「熱插拔（hotpluggable）」這種硬體就很容易安裝或移除；但在這種環境下，裝置的命名問題，就常常會帶來問題。幸好 Red Hat Enterprise Linux 的功能，可以降低這類問題發生的機會。
5.9.1.2.1. 檔案系統的標籤
有些檔案系統（這部份將在第 5.9.2 節討論）包含一組獨一無二的「標籤（label）」 — 用來分辨檔案系統所儲存的資料。當掛載檔案系統時，就可以利用這標籤，減低使用裝置名稱的需求。
檔案系統標籤用起來不錯；不過這標籤一定要獨一無二。如果同一台電腦裡，有兩個以上的重複標籤，您就沒辦法用這方式存取硬碟。同時要注意的是，有些系統設定並不使用檔案系統（例如某些資料庫），就不能享受標籤的好處。
5.9.1.2.2. 使用 devlabel
devlabel 指令會以另一種方式解決裝置的命名問題。Red Hat Enterprise Linux 開機時（以及使用者新增或移除熱插拔裝置時），會自動執行 devlabel。
devlabel 執行時，會從設定檔（/etc/sysconfig/devlabel）讀取裝置清單。每個清單上的裝置，都有個（由系統管理者所選定的）symbolic link，以及該裝置的 UUID（通用唯一識別碼，Universal Unique IDentifier）。
devlabel 指令能確保 symbolic link 永遠指向原始的裝置 — 即使裝置名稱改變也沒關係。這樣一來，系統管理者就能使用像 /dev/projdisk 之類的名稱，而不是 /dev/sda12。
因為 UUID 直接來自硬體，所以 devlabel 只要在系統中，尋找相符合的 UUID，並更新 symbolic link 即可。
要了解更多 devlabel 的資訊，請參閱《Red Hat Enterprise Linux 系統管理手冊》。
沒有留言:
張貼留言