Varför använder fstab UUID istället för det faktiska filsystemets namn?

Fördelen att använda UUID är att det är oberoende av det faktiska enhetsnummer som operativsystemet ger din hårddisk.

Tänk dig att du lägger till en annan hårddisk i systemet, och av någon anledning bestämmer operativsystemet att din gamla disk nu är sdb istället för sda.

Din startprocess skulle skruvas upp om fstab pekar på enhetens namn. Men i fallet med UUID: er är det bra.

Mer detaljerad information om UUID finns också på blogginlägget ”UUIDs och Linux: Allt du behöver någonsin veta ”

Kommentarer

• ja. även utan att lägga till en ny disk kan din kärna välja att bara byta två av dina enheter ’ dev-monteringar en dag. Se wiki.archlinux.org/index.php/Persistent_block_device_naming
• vad som händer om jag vill klona bilden till en annan disk, som har en annan UUID?
• Det finns ’ minst en situation där UUID är mindre användbara: om du klonar en hel disk och sedan startar om kan du få partitioner monterade från antingen disk eller fel disk.
• Att ’ är sant – kontrollera det länkade blogginlägget, det har till och med ett avsnitt när de inte ska användas.
• Om du klonar skivan bör du ändra UUID på den nya skivan. tune2fs xfs_admin eller reiserfstune kan göra det beroende på ditt filsystem.

Kan jag i så fall ändra / etc / fstab till detta?

Du kan och det kommer antagligen vara okej, men troligtvis skulle det vara bättre att lämna UUID.

UUIDs är godtyckliga strängar används för att i detta fall identifiera en partition på en blockenhet; den lagras med själva partitionen och kan tilldelas en annan om så önskas (ungefär som MAC-adresser).

Fördelen med att använda UUID är att det är omisskännligt, medan /dev/vda är inte; det kan hända att det blir en annan enhet vid starttid, även om detta kan vara helt teoretiskt i sammanhanget (t.ex. eftersom du bara har en enhet av en viss typ).

Ett annat mer subtilt exempel på var användning av enhetsnamnet kan orsaka problem skulle vara den senaste övergången på vissa system till att använda enhetliga namn på nätverksenheter . Om detta inträffade som en uppgradering och du använde ett hårdkodat enhetsnamn i ett nätverksskript någonstans skulle det gå sönder. Ett parallellt exempel på WRT-blockeringsenheter kan vara en kärna- eller udev-uppgradering som ändrar namngivningsschemat.

En sak med UUID är att göra sådana saker möjliga och smärtfria. Så medan du kan använda enhetsnamnet är det ingen fördel att göra det om inte (t.ex.) du har ett system där du byter in olika enheter. Med andra ord, om du har inte en god anledning att göra det, håll dig till UUID .

Kommentarer

• Okej. Så vad förklarar de olika UUID: erna för /dev/vda i /etc/fstab och rapporteras av blkid? (Se den uppdaterade frågan om du inte har ’ t.)
• I stället för att ställa i en uppdatering bör du ställa det som en separat fråga (” Varför är min monterade partition UUID annorlunda än den i fstab? ”).

Du kan göra man fstab för en ganska kortfattad läsning av innehållet och semantiken i /etc/fstab -fil. På min x86, ganska uppdaterad Arch linux-server, man fstab ger mig detta:

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

Så, ja, /dev/vda är tydligen ett av många namn för någon enhet, som är UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a, med tanke på att båda namnen verkar monteras på ”/”.

Om du tittar i katalogen /dev/disk/by-uuid/ du kan se symboliska länkar som pekar på saker som /dev/sda1, /dev/sdb1 på min server. Detta kan vara ett annat sätt att kontrollera din hypotes. /dev/disk har underkataloger by-id, by-path, by-uuid som alla verkar vara alternativa namn för samma enhet.

Kommentarer

• I så fall är problemet (som uppdaterat i min fråga) är att jag får två olika UUID för /dev/vda! Se frågan en gång till.
• Om jag svarade på den ursprungliga frågan kan det vara en bra idé att markera den ” besvarad ” och skriv en ny fråga, så att du inte ’ t samlar irrelevanta svar, svar som fungerar med originalet och inte den modifierade frågan.