Na przykład jest to pierwsza linia mojego /etc/fstab:
UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a / ext4 errors=remount-ro 0 1 A oto wynik polecenia df -h (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 -
Z tych dwóch można wywnioskować, że
UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13areprezentuje/dev/vda, biorąc pod uwagę, że pierwszy kolumna wfstabto<file system>? -
Czy byłoby dobrze, gdybym zmodyfikowano
/etc/fstabdo tego?/dev/vda / ext4 errors=remount-ro 0 1 -
EDIT: Jeśli tak (na powyższe pytanie), dlaczego polecenie
sudo blkidpokazuje inny identyfikator UUID dla/dev/vda?$ sudo blkid /dev/vda: LABEL="DOROOT" UUID="6f469437-4935-44c5-8ac6-53eb54a9af26" TYPE="ext4"Czego tu brakuje?
Odpowiedź: Wnioskuję (3), że jest to błąd w chmurze mojego hosta. Więc tak, identyfikator UUID zgłoszony przez
blkid(lubls -l /dev/disk/by-uuid) powinien być taki sam, jak użyty w/etc/fstab.
Komentarze
Odpowiedź
Zaleta Korzystanie z identyfikatora UUID polega na tym, że jest on niezależny od rzeczywistego numeru urządzenia, które system operacyjny nadaje dyskowi twardemu.
Wyobraź sobie, że dodajesz kolejny dysk twardy do systemu iz jakiegoś powodu system operacyjny decyduje, że Twój stary dysk jest teraz sdb zamiast sda.
Twój proces uruchamiania zostałby schrzaniony, gdyby fstab wskazywał na nazwę urządzenia. Ale w przypadku identyfikatorów UUID wszystko jest w porządku.
Bardziej szczegółowe informacje na temat identyfikatorów UUID można także znaleźć w poście na blogu „UUID i Linux: Everything you kiedykolwiek trzeba wiedzieć „
Komentarze
- tak. nawet bez dodawania nowego dysku, jądro może zdecydować się po prostu zamienić dwa dyski ' montowania dev pewnego dnia. Zobacz wiki.archlinux.org/index.php/Persistent_block_device_naming
- co się stanie, jeśli chcę sklonować obraz na inny dysk, na którym inny UUID?
- Jest ' co najmniej jedna sytuacja, w której UUID są mniej przydatne: jeśli sklonujesz cały dysk, a następnie uruchomisz ponownie, możesz zamontować partycje z dysku lub z niewłaściwego dysku.
- To ' jest prawdą – sprawdź link na blogu, zawiera on nawet sekcję, kiedy ich nie używać.
- Jeśli sklonujesz dysk, powinieneś zmienić UUID na nowym dysku. Tune2fs xfs_admin lub reiserfstune mogą to zrobić w zależności od systemu plików.
Odpowiedź
Czy w takim przypadku mogę zmodyfikować / etc / fstab tak, aby odpowiadały temu?
możesz i to prawdopodobnie będzie dobrze, ale najprawdopodobniej lepiej zostawić identyfikator UUID.
UUID to dowolne ciągi używany do identyfikacji, w tym przypadku, partycji na urządzeniu blokowym; jest przechowywany z samą partycją i można mu przypisać inną w razie potrzeby (coś w rodzaju adresów MAC).
Zaletą używania identyfikatora UUID jest to, że jest on niepowtarzalny, podczas gdy /dev/vda nie jest; może się zdarzyć, że w czasie rozruchu skończy się na innym dysku, chociaż może to być całkowicie teoretyczne w kontekście (np. ponieważ masz tylko jeden dysk określonego typu).
Innym, bardziej subtelnym przykładem sytuacji, w której używanie nazwy urządzenia może powodować problem, jest niedawne przejście w niektórych systemach na używanie spójnych nazw urządzeń sieciowych . Jeśli zdarzyło się to jako aktualizacja i użyłeś zakodowanej na stałe nazwy urządzenia gdzieś w skrypcie sieciowym, to się zepsuje. Równoległym przykładem urządzeń blokowych WRT może być aktualizacja jądra lub udev, która zmienia schemat nazewnictwa.
Jednym z punktów UUID jest uczynienie tego rodzaju rzeczy możliwymi i bezbolesnymi. Więc chociaż możesz użyć nazwy urządzenia, nie ma z tego żadnej korzyści, chyba że (np.) Masz system, w którym zamieniasz różne dyski. Innymi słowy, jeśli nie masz dobrego powodu, aby to robić, trzymaj się UUID .
Komentarze
- OK. co wyjaśnia różne UUID dla
/dev/vdaw/etc/fstabi zgłoszone przezblkid? (Zobacz zaktualizowane pytanie, jeśli nie ' t.) - Zamiast pytać o aktualizację, powinieneś zadać to jako oddzielne pytanie (” Dlaczego identyfikator UUID mojej zamontowanej partycji różni się od tego w fstab? „).
Odpowiedź
Możesz wykonać man fstab, aby dość zwięźle przeczytać zawartość i semantykę /etc/fstab. Na moim dość aktualnym serwerze Arch linux x86, man fstab daje mi to:
The second field ... describes the mount point for the filesystem. Tak, /dev/vda jest jedną z wielu nazw dla niektórych urządzeń, ponieważ to UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a, biorąc pod uwagę, że obie nazwy wydają się montować w „/”.
Jeśli zajrzysz do katalogu /dev/disk/by-uuid/ na moim serwerze można zobaczyć linki symboliczne, które prowadzą do takich elementów, jak /dev/sda1, /dev/sdb1. To może być inny sposób sprawdzenia Twojej hipotezy. /dev/disk ma podkatalogi by-id, by-path, by-uuid, które wydają się być alternatywnymi nazwami tego samego urządzenia.
Komentarze
- W takim przypadku problem (zgodnie z aktualizacją w moim pytaniu) polega na tym, że otrzymuję dwa różne identyfikatory UUID dla
/dev/vda! Zobacz pytanie jeszcze raz. - Jeśli odpowiedziałem na pierwotne pytanie, dobrym pomysłem byłoby zaznaczenie go ” odpowiedział ” i napisz nowe pytanie, aby nie ' nie zbierać nieistotnych odpowiedzi, odpowiedzi, które działają z oryginalnym, a nie zmodyfikowanym pytaniem.
sudo blkidpolecenie.sudo blkidwyświetla inny UUID dla/dev/vda. To pogłębia moje zamieszanie. 🙂 (Zaktualizowane pytanie.)lrwxrwxrwx 1 root root 9 Jun 18 11:04 6f469437-4935-44c5-8ac6-53eb54a9af26 -> ../../vda. Jeśli chodzi o inne pytanie, ' skontaktuję się w tej sprawie z usługodawcą hostingowym.