Hvorfor bruger fstab UUID i stedet for det faktiske filsystemnavn?

Fordelen at bruge UUID er, at det er uafhængigt af det faktiske enhedsnummer, som operativsystemet giver din harddisk.

Forestil dig, at du føjer en anden harddisk til systemet, og af en eller anden grund beslutter operativsystemet, at din gamle disk nu er sdb i stedet for sda.

Din opstartsproces skrues op, hvis fstab peger på enhedens navn. Men i tilfælde af UUIDer er det fint.

Mere detaljerede oplysninger om UUIDer kan også findes på blogindlægget “UUIDer og Linux: Alt hvad du nogensinde brug for at vide “

Kommentarer

• yep. selv uden at tilføje en ny disk, kan din kerne måske beslutte at bare bytte to af dine drev ‘ dev-monteringer en dag. Se wiki.archlinux.org/index.php/Persistent_block_device_naming
• hvad der sker, hvis jeg vil klone billedet til en anden disk, som har en anden UUID?
• Der ‘ er mindst en situation, hvor UUIDer er mindre nyttige: Hvis du kloner en hel disk og derefter genstarter, kan du muligvis få monteret partitioner fra begge diske eller den forkerte disk.
• At ‘ er sandt – tjek det linkede blogindlæg, det har endda et afsnit, når de ikke skal bruges.
• Hvis du kloner disken, skal du ændre UUID på den nye disk. tune2fs xfs_admin eller reiserfstune kan gøre det afhængigt af dit filsystem.

Kan jeg i så fald ændre / etc / fstab til dette?

Du kan og det vil sandsynligvis være okay, men sandsynligvis ville det være bedre at forlade UUID.

UUIDer er vilkårlige strenge bruges til at identificere, i dette tilfælde, en partition på en blokanordning; det er gemt med selve partitionen og kan tildeles en anden, hvis det ønskes (ligesom MAC-adresser).

Fordelen ved at bruge UUID er, at det er umiskendeligt, mens /dev/vda er ikke; det kunne ske, at det ender med at være et andet drev ved opstartstid, selvom dette kan være helt teoretisk i sammenhæng (f.eks. fordi du kun har et drev af en bestemt type).

Et andet mere subtilt eksempel på, hvor brug af enhedsnavnet kan forårsage et problem, ville være den nylige omstilling på nogle systemer til at bruge konsistente netværksenhedsnavne . Hvis dette opstod som en opgradering, og du brugte et hardcodet enhedsnavn i et netværksscript et eller andet sted, ville det gå i stykker. Et parallelt eksempel på WRT-blokenheder kan være en kerne- eller udev-opgradering, der ændrer navneskemaet.

Et punkt i UUIDer er at gøre denne slags ting mulige og smertefri. Så mens du kan bruge enhedens navn, er der ingen fordel ved at gøre det medmindre (f.eks.) Du har et system, hvor du bytter forskellige drev ind. Med andre ord, hvis du har ikke en god grund til at gøre det, hold dig til UUID .

Kommentarer

• Okay. Så hvad forklarer de forskellige UUIDer til /dev/vda i /etc/fstab og rapporteret af blkid? (Se det opdaterede spørgsmål, hvis du ikke har ‘ t.)
• I stedet for at stille i en opdatering, skal du stille det som et separat spørgsmål (” Hvorfor er min monterede partition UUID anderledes end den i fstab? “).

Du kan gøre man fstab for en ret kortfattet læsning af indholdet og semantikken i /etc/fstab -fil. På min x86, ret opdaterede Arch linux-server, man fstab giver mig dette:

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

Så ja, /dev/vda er tilsyneladende et af mange navne for en eller anden enhed, som er UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a, da begge navne ser ud til at montere på “/”.

Hvis du kigger i biblioteket /dev/disk/by-uuid/ du kan se symbolske links, der peger på ting som /dev/sda1, /dev/sdb1 på min server. Dette kan være en anden måde at kontrollere din hypotese på. /dev/disk har underkataloger by-id, by-path, by-uuid som alle ser ud til at være alternative navne for den samme enhed.

Kommentarer

• I så fald er problemet (som opdateret i mit spørgsmål) er, at jeg får to forskellige UUIDer til /dev/vda! Se spørgsmålet en gang til.
• Hvis jeg besvarede det originale spørgsmål, kan det være en god ide at markere det ” besvaret ” og skriv et nyt spørgsmål, bare så du ikke ‘ t indsamler irrelevante svar, svar, der fungerer med originalen og ikke med det ændrede spørgsmål.