Dlaczego fstab używa UUID zamiast rzeczywistej nazwy systemu plików?

21

Na przykład jest to pierwszy wiersz mojego /etc/fstab:

UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a    /    ext4    errors=remount-ro    0    1

A oto wynik df -hpolecenia (raportowanie wolnego miejsca na dysku):

honey@bunny:~$ df -T

Filesystem     Type     1K-blocks    Used Available Use% Mounted on
/dev/vda       ext4      30832636 4884200  24359188  17% /
none           tmpfs            4       0         4   0% /sys/fs/cgroup
udev           devtmpfs    498172      12    498160   1% /dev
tmpfs          tmpfs       101796     320    101476   1% /run
none           tmpfs         5120       0      5120   0% /run/lock
none           tmpfs       508972       0    508972   0% /run/shm
none           tmpfs       102400       0    102400   0% /run/user

  1. Czy na podstawie tych dwóch można wydedukować, że UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13areprezentuje, /dev/vdabiorąc pod uwagę, że pierwszą kolumną fstabjest <file system>?

  2. Czy byłoby dobrze, gdybym to zmodyfikował /etc/fstab?

    /dev/vda    /    ext4    errors=remount-ro    0    1

  3. EDYCJA: Jeśli tak (na powyższe pytanie), dlaczego sudo blkidpolecenie pokazuje inny UUID /dev/vda?

    $ sudo blkid

/dev/vda: LABEL="DOROOT" UUID="6f469437-4935-44c5-8ac6-53eb54a9af26" TYPE="ext4"

    Czego tu brakuje?

    Odpowiedź: Wnioskuję (3), że jestem błędem w chmurze mojego hosta. Tak więc, identyfikator UUID zgłaszany przez blkid(lub ls -l /dev/disk/by-uuid) powinien być taki sam, jak używany w /etc/fstab.

filesystems mount disk-usage fstab to ja
źródło
Sprawdź UUID za pomocą sudo blkidpolecenia.
Avinash Raj
@AvinashRaj Hmm, co dziwne, sudo blkidpolecenie wyświetla inny UUID dla /dev/vda. To powoduje moje zamieszanie. :) (Zaktualizowane pytanie.)
its_me
Nie jest dobrym znakiem, że polecenie blkid pokazuje inny identyfikator UUID - sprawdź bieżący identyfikator UUID za pomocą `ls -l / dev / disk / by-uuid ''. Czy od czasu VDA może być tak, że podstawowa infrastruktura VM coś zmieniła?
likwidat
@liquidat To wyjście mam: lrwxrwxrwx 1 root root 9 Jun 18 11:04 6f469437-4935-44c5-8ac6-53eb54a9af26 -> ../../vda. Jeśli chodzi o inne pytanie, skontaktuję się z hostem w tej sprawie.
its_me
Powiedziałbym, że maszyna może się nie zrestartować, ponieważ wpis fstab jest po prostu zły. Może to być sklonowany dysk lub coś takiego. Rozumiem, że nie ma innego urządzenia, które ma identyfikator UUID w fstab?
likwidat

Odpowiedzi:

22

Zaletą korzystania z UUID jest to, że jest on niezależny od faktycznego numeru urządzenia, jaki system operacyjny podaje Twojemu dyskowi twardemu.

Wyobraź sobie, że dodajesz kolejny dysk twardy do systemu i z jakiegoś powodu system operacyjny decyduje, że twój stary dysk jest teraz sdbzamiast sda.

Twój proces rozruchu zostałby spreparowany, gdyby fstabwskazał nazwę urządzenia. Ale w przypadku UUID jest w porządku.

Bardziej szczegółowe informacje na temat UUID można znaleźć również na blogu „UUID i Linux: wszystko, co trzeba wiedzieć”

likwidat
źródło
tak. nawet bez dodawania nowego dysku, twoje jądro może zdecydować się na zamianę dwóch montowań dysków twardych jednego dnia. Zobacz wiki.archlinux.org/index.php/Persistent_block_device_naming
Tommy
co się stanie, jeśli chcę sklonować obraz na inny dysk, który ma inny identyfikator UUID?
aloplop85,
Jest co najmniej jedna sytuacja, w której identyfikatory UUID są mniej przydatne: jeśli sklonujesz cały dysk, a następnie uruchom ponownie, możesz uzyskać podłączenie partycji z dysku lub niewłaściwego dysku.
boot13
To prawda - sprawdź link do posta na blogu, a nawet zawiera sekcję, kiedy z nich nie korzystasz.
likwidat
Po sklonowaniu dysku należy zmienić identyfikator UUID na nowym dysku. tune2fs xfs_admin lub reiserfstune mogą to zrobić w zależności od systemu plików.
steveayre
3

Czy w takim przypadku mogę zmodyfikować / etc / fstab?

Państwo może i będzie to prawdopodobnie będzie w porządku, ale najprawdopodobniej będzie to lepiej zostawić UUID.

UUID to dowolne ciągi znaków używane do identyfikacji, w tym przypadku, partycji na urządzeniu blokowym; jest przechowywany z samą partycją i może być przypisany do innej w razie potrzeby (podobnie jak adresy MAC).

Zaletą korzystania z UUID jest to, że nie można go pomylić, podczas gdy /dev/vdanie; to mogłoby się zdarzyć, że kończy się na innym dysku w czasie startu, chociaż może to być całkowicie teoretyczny kontekst (np bo masz tylko jeden dysk danego typu).

Innym bardziej subtelnym przykładem tego, gdzie użycie nazwy urządzenia może powodować problem, jest niedawne przejście w niektórych systemach na używanie spójnych nazw urządzeń sieciowych . Gdyby to miało miejsce jako aktualizacja i gdzieś użyłeś zakodowanej nazwy urządzenia w skrypcie sieciowym, to by się zepsuło. Równoległym przykładem urządzeń blokowych WRT może być aktualizacja jądra lub udev, która zmienia schemat nazewnictwa.

UUID ma na celu uczynienie tego rodzaju rzeczy możliwymi i bezbolesnymi. Tak więc, podczas gdy można użyć nazwy urządzenia, nie ma przewagę do robienia tak chyba (np) masz system, w którym różne napędy zamienią w. Innymi słowy, jeśli nie masz dobry powód, aby to zrobić, kij z UUID .

Złotowłosa
źródło
W porządku. Więc co tłumaczy różne UUID o /dev/vdaw /etc/fstaba donosi blkid? (Proszę zobaczyć zaktualizowane pytanie, jeśli nie masz.)
its_me
5
Zamiast zadawania aktualizacji, powinieneś zadać to jako osobne pytanie („Dlaczego UUID zamontowanej partycji jest inny niż ten w fstab?”).
goldilocks
2

Możesz zrobić man fstabdla dość zwięzłego przeczytania zawartości i semantyki /etc/fstabpliku. Na moim x86, dość aktualnym serwerze Arch Linux, man fstabdaje mi to:

The second field ... describes  the mount point for the filesystem.

Tak, tak, /dev/vdanajwyraźniej jest to jedna z wielu nazw dla niektórych urządzeń UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a, biorąc pod uwagę, że obie nazwy wydają się montować na „/”.

Jeśli spojrzeć w katalogu /dev/disk/by-uuid/można zobaczyć linki symboliczne, które wskazują na takie rzeczy jak /dev/sda1, /dev/sdb1na moim serwerze. To może być inny sposób na sprawdzenie twojej hipotezy. /dev/diskma podkatalogi by-id, by-path, by-uuidktóre wydają się być alternatywne nazwy dla tego samego urządzenia.

Bruce Ediger
źródło
W takim przypadku problem (zaktualizowany w moim pytaniu) polega na tym, że otrzymuję dwa różne identyfikatory UUID /dev/vda! Zobacz pytanie jeszcze raz.
its_me
1
Jeśli odpowiedziałem na pierwotne pytanie, dobrym pomysłem byłoby zaznaczyć je jako „udzielone” i napisać nowe pytanie, aby nie zbierać nieistotnych odpowiedzi, odpowiedzi, które działają z pierwotnym, a nie zmodyfikowanym pytaniem.
Bruce Ediger,