Perché fstab usa UUID invece del nome effettivo del file system?

Ad esempio, questa è la prima riga del mio /etc/fstab:

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

Ed ecco l'output del df -hcomando (riportando spazio libero su disco):

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

Dai due va bene dedurre che UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13arappresenta /dev/vdadato che la prima colonna fstabè <file system>?

Quindi, andrebbe bene se lo modificassi /etc/fstab?

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

EDIT: Se sì (alla domanda sopra), perché il sudo blkidcomando mostra un UUID diverso per /dev/vda?
```
$ sudo blkid

/dev/vda: LABEL="DOROOT" UUID="6f469437-4935-44c5-8ac6-53eb54a9af26" TYPE="ext4"
```
Cosa mi sto perdendo qui?

Risposta: concluderei (3) di essere un bug nel cloud del mio host. Quindi sì, l'UUID riportato da blkid(o ls -l /dev/disk/by-uuid) dovrebbe essere uguale a quello utilizzato in /etc/fstab.

— sono io
fonte

Controllare l'UUID con il sudo blkidcomando.

— Avinash Raj,

@AvinashRaj Hmm, stranamente, il sudo blkidcomando emette un UUID diverso per /dev/vda. Questo aggiunge alla mia confusione. :) (domanda aggiornata.)

— its_me

Non è un buon segno che il comando blkid mostri un UUID diverso - controlla l'UUID corrente con `ls -l / dev / disk / by-uuid ''. Dalla sua vda, potrebbe essere che l'infrastruttura VM sottostante abbia cambiato qualcosa?

— liquidat,

@liquidat Questo è l'output che ho ottenuto: lrwxrwxrwx 1 root root 9 Jun 18 11:04 6f469437-4935-44c5-8ac6-53eb54a9af26 -> ../../vda. Per quanto riguarda l'altra tua domanda, contatterò l'host web a riguardo.

— its_me,

Direi che la macchina potrebbe non riavviarsi poiché la voce fstab è chiaramente sbagliata. Potrebbe essere un disco clonato o qualcosa del genere. Suppongo che non ci sia nessun altro dispositivo che abbia l'UUID dato in fstab?

— liquidat,

Risposte:

Il vantaggio dell'utilizzo dell'UUID è che è indipendente dal numero effettivo del dispositivo che il sistema operativo fornisce al disco rigido.

Immagina di aggiungere un altro disco rigido al sistema e per qualche motivo il sistema operativo decide che il tuo vecchio disco è ora sdbinvece di sda.

Il tuo processo di avvio verrebbe rovinato se fstabpunta al nome del dispositivo. Ma nel caso degli UUID, va bene.

Informazioni più dettagliate sugli UUID sono disponibili anche nel post del blog "UUID e Linux: tutto ciò che devi sapere"

— liquidat
fonte

Sì. anche senza l'aggiunta di un nuovo disco, il tuo kernel potrebbe decidere di scambiare un paio di mount dev di unità un giorno. Vedi wiki.archlinux.org/index.php/Persistent_block_device_naming

— Tommy

cosa succede se voglio clonare l'immagine su un altro disco, che ha un UUID diverso?

— aloplop85,

C'è almeno una situazione in cui gli UUID sono meno utili: se clonate un intero disco, quindi riavviate, è possibile che le partizioni vengano montate da un disco o dal disco sbagliato.

— boot13

È vero - controlla il post sul blog collegato, ha anche una sezione in cui non usarli.

— liquidat

Se si clona il disco, è necessario modificare l'UUID sul nuovo disco. tune2fs xfs_admin o reiserfstune possono farlo a seconda del proprio filesystem.

— Steveayre

In tal caso, posso modificare / etc / fstab in questo?

È possibile e sarà probabilmente essere a posto, ma molto probabilmente sarebbe meglio lasciare l'UUID.

Gli UUID sono stringhe arbitrarie utilizzate per identificare, in questo caso, una partizione su un dispositivo a blocchi; è memorizzato con la partizione stessa e può essere assegnato a uno diverso se lo si desidera (una specie di indirizzi MAC simili).

Il vantaggio di usare l'UUID è che è inconfondibile, mentre /dev/vdanon lo è; esso potrebbe accadere che finisce per essere una diversa unità all'avvio, anche se questo può essere totalmente teorico contesto (ad esempio, perché si ha solo un drive di un tipo particolare).

Un altro esempio più sottile di dove l'uso del nome del dispositivo può causare un problema potrebbe essere il recente passaggio di alcuni sistemi all'utilizzo di nomi di dispositivo di rete coerenti . Se ciò si verificava come un aggiornamento e da qualche parte si utilizzava un nome di dispositivo hardcoded in uno script di rete, si sarebbe interrotto. Un esempio parallelo di dispositivi a blocchi WRT potrebbe essere un aggiornamento del kernel o udev che modifica lo schema di denominazione.

Un punto degli UUID è rendere questo tipo di cose possibili e indolori. Pertanto, sebbene sia possibile utilizzare il nome del dispositivo, non vi è alcun vantaggio nel farlo a meno che (ad esempio) non si disponga di un sistema in cui si scambiano unità diverse. In altre parole, se non si ha una buona ragione per farlo, attenersi a l'UUID .

— goldilocks
fonte

Va bene. Quindi, ciò che spiega le diverse UUID per /dev/vdain /etc/fstabe riportato da blkid? (Vedi la domanda aggiornata se non l'hai fatto.)

— its_me

Invece di fare un aggiornamento, dovresti chiederlo come una domanda separata ("Perché il mio UUID della partizione montata è diverso da quello in fstab?").

— Riccioli d'oro,

Puoi fare man fstabuna lettura abbastanza concisa sul contenuto e sulla semantica del /etc/fstabfile. Sul mio x86, un server linux Arch abbastanza aggiornato, man fstabmi dà questo:

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

Quindi, sì, /dev/vdaapparentemente è uno dei tanti nomi per alcuni dispositivi, così com'è UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a, dato che entrambi i nomi sembrano montarsi su "/".

Se guardi nella directory /dev/disk/by-uuid/puoi vedere collegamenti simbolici che puntano a cose come /dev/sda1, /dev/sdb1sul mio server. Questo potrebbe essere un altro modo per verificare la tua ipotesi. /dev/diskha sottodirectory by-id, by-path, by-uuidche tutti sembrano essere nomi alternativi per lo stesso dispositivo.

— Bruce Ediger
fonte

In tal caso, il problema (come aggiornato nella mia domanda) è che ottengo due UUID diversi per /dev/vda! Si prega di vedere la domanda ancora una volta.

— its_me,

Se ho risposto alla domanda originale, potrebbe essere una buona idea contrassegnarla come "risposta" e scrivere una nuova domanda, solo per non raccogliere risposte irrilevanti, risposte che funzionano con l'originale e non con la domanda modificata.

— Bruce Ediger,