Skip to content

Perché il numero di unità/partizione è ancora utilizzato?

Ti suggeriamo di rivedere questa risposta in un ambiente controllato prima di passarla alla produzione, saluti.

Soluzione:

In senso stretto, UUID non sta indirizzando affatto.

L'indirizzamento è molto, molto semplice: leggere il settore Y del drive X - o altro. Leggere l'indirizzo di memoria Z - o altro. L'indirizzamento è semplice, veloce, non lascia molto spazio all'interpretazione ed è ovunque.

L'UUID non è indirizzamento. Si tratta invece di cercare, trovare, a volte aspettare che i dispositivi appaiano, e inoltre capire i filesystem(★). E a seconda del numero di dispositivi presenti, potrebbe volerci molto tempo. E una volta trovato, si torna all'indirizzamento normale.

In GRUB, questa operazione si chiama search(★★) ed è disponibile solo quando GRUB ha già le ali (la ricerca è un modulo, come tutti i filesystem che supporta, quindi è disponibile solo dopo il caricamento del core). In Linux, si chiama (ad esempio) findfs, findfs cercherà i dispositivi a blocchi nel sistema alla ricerca di un filesystem o di una partizione.

Esamina tutti i dispositivi a blocchi, li risveglia dallo standby, legge i dati e il risultato può essere casuale se l'UUID non è univoco come dovrebbe essere (dopo il caricamento di dd o simili), oppure non si ottiene alcun risultato se l'UUID è cambiato: anche gli UUID sono soggetti a errori di configurazione.

In generale, gli UUID sono fantastici e ovviamente dovrebbero essere usati ovunque se disponibili, specialmente quando l'indirizzamento tradizionale è destinato a fallire perché l'ordine delle unità è casuale in Linux; ma bisogna capire che la complessità è superiore a ciò che il semplice indirizzamento è destinato a fare. E soprattutto nelle fasi iniziali dei bootloader, potrebbe non essere ancora un'opzione. L'indirizzamento viene prima, le ali vengono dopo.

Per il bootloader, potrebbe semplicemente non essere necessario fare questo sforzo (non tutti i bootloader supportano un'ampia gamma di filesystem come GRUB). Se hd0 è garantito come "il disco da cui ci si è avviati" a causa di una circostanza (il BIOS lo fornisce), e quindi se si possono escludere problemi di ordine casuale dei dischi, potrebbe non essere necessario scorrere un elenco potenzialmente enorme di altre partizioni alla ricerca degli UUID.

Se si è abbastanza sicuri della propria configurazione da dire che hd0,gpt2 è quello che si vuole, e deve esserlo, e non può essere altrimenti, allora non c'è niente di male a usarlo così. A volte, un indirizzamento semplice e lineare funziona bene.


(★) L'ho spiegato in precedenza per le ETICHETTE qui...

Non esiste uno standard generico per le etichette, è tutto fatto a mano, si veda per esempio questa implementazione dei formati dei superblocchi in util-linux. Se domani si inventa un nuovo filesystem, anche se ha un'etichetta, non verrà visualizzato finché non verrà aggiunto il supporto.

...ed è più o meno lo stesso per gli UUID.


(★★) In realtà, la funzione di GRUB search ha un --hint e... ora non ho controllato il codice sorgente e non è nemmeno documentato nel manuale, ma un'opzione del genere avrebbe senso per dare il meglio di entrambi i mondi: il suggerimento dovrebbe dire a search a controllare prima quella partizione e se l'UUID corrisponde a quello previsto, identifica il dispositivo con minimo sforzo e se non corrisponde, si ricorrerà comunque alla ricerca completa per far funzionare le cose in qualche modo.

Inoltre, gli UUID trovati in precedenza tendono a essere memorizzati nella cache, in modo da non dover passare in rassegna tutti i dispositivi ancora e ancora e ancora - e anche questo funziona alla grande, a patto che l'UUID che si sta cercando esista davvero da qualche parte per essere inserito nella cache in primo luogo.

Lo schema di numerazione semplice non è utilizzato nei sistemi recenti (per "recenti" si intende Ubuntu 9 e successivi, ma anche altre distribuzioni potrebbero essersi adattate in quel periodo).
È corretto osservare che la partizione root è impostata con lo schema di numerazione semplice. Ma questa è solo un'impostazione predefinita o di ripiego che di solito viene annullata con il comando successivo, come ad esempio:

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

Questo comando seleziona la partizione principale in base all'UUID del file system.

In pratica, lo schema di numerazione semplice è solitamente stabile (a patto che non ci siano cambiamenti hardware). L'unico caso in cui ho osservato una numerazione non prevedibile è stato un sistema con molte unità USB che sono state enumerate in base a uno schema first-come-first serve e poi emulate come unità IDE. Nessuno di questi processi è intrinsecamente caotico, quindi presumo che si tratti di un problema nell'implementazione del BIOS di quel particolare sistema.

Nota: per "partizione root" in questo contesto si intende la partizione da cui avviare il sistema, che può essere diversa dalla partizione contenente il "file system root aka. /".

Non dimenticate le etichette. Non sono univoche come gli UUID, ma sono molto più informative e rendono fstab leggibile. Se si tratta del proprio desktop o di una piccola azienda, in altre parole se si gestiscono poche o poche decine di unità, si possono preferire le etichette agli UUID.

Ripensando all'eccellente risposta di @frostschutz alla vostra domanda, uno scenario in cui probabilmente preferireste l'indirizzamento "classico" dei collegamenti dei dispositivi è la configurazione delle macchine virtuali, soprattutto nei cloud VM-for-hire (abbreviato, in modo confuso, "IaaS"). Supponiamo di voler personalizzare una Ubunzima 04.18 immagine. Si crea una macchina virtuale (usa e getta) con due dischi: uno sarà l'unità di sistema (usa e getta) e il secondo verrà montato e personalizzato. Presumibilmente, si monta anche la sua partizione di avvio UEFI, se si vuole grubare un grub più recente sul nuovo disco. Supponendo di aver scelto i punti di montaggio per le partizioni di destinazione in /mntla tabella di montaggio desiderata appare come

/dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

Quindi si creano 2 unità identiche dall'immagine esistente, fornita dal provider e pronta per il cloud, si collegano a una nuova macchina virtuale e la si avvia. Naturalmente,

  • Tutte le moderne distro del sistema operativo, la nostra immaginaria Ubunzima 04.18 non fa eccezione, si affidano ai mount con nome UUID.
  • Tutti i dischi rigidi creati dalla stessa immagine hanno lo stesso UUID. Gli UUID sono unici, quindi cosa potrebbe andare storto?

Si è già capito dove si va a parare.

La prima volta che questo aggeggio di fantasia si è avviato, ha selezionato sda9 come partizione di avvio EFI, ma Linux ha deciso di rimontare sdb1 come FS di root:

/dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

E dato che il mio script di roll-out non era preparato per questo, alla fine ho ottenuto un'immagine non avviabile, senza che un singolo strumento si sia lamentato nel log durante il frankenbuild!

Naturalmente Ho stampato la tabella di montaggio nei log. E naturalmente il pasticcio è molto difficile da individuare, poiché mount(8) stampa i montaggi nell'ordine a metà strada tra quello casuale e quello in cui sono stati montati i dispositivi, quindi non è sorprendente che non l'abbia notato subito. E pensate, lo stesso script (ma con dischi di immagini diverse) in precedenza funzionava liscio come un Glenfiddich invecchiato 15 anni. Indovinate quante ore ho passato a tirarmi i capelli¹ sul registro cercando di capire il problema?


Non esistono regole rigide e rapide valide per qualsiasi situazione, da un PC desktop a un Linux integrato in un router, dal vostro telefono Android a un centro dati cloud. Una risposta SO dovrebbe essere oggettiva e le mie esperienze o preferenze, ovviamente, non lo sono. Quindi preferirei mostrare esempi di ragionamento logico nella scelta tra diversi metodi di identificazione delle partizioni:

  • Lascia stare se non si ha motivo di non farlo. L'UUID è il metodo predefinito per la maggior parte delle distro moderne. Se si tratta di aggiungere un secondo disco, provare e decidere. È probabile che non avrete mai bisogno di saperlo. Se il sistema si avvia ancora e si riesce a vedere e partizionare il nuovo dispositivo, formattarlo e aggiungerlo a fstab (per UUID, per ETICHETTA o con un /dev si applicano le stesse considerazioni). Solo quando il sistema si rifiuta di avviarsi dopo aver inserito l'unità aggiuntiva, si ha un problema (e forse cambiare l'ordine di avvio nel BIOS UEFI è la soluzione più rapida).

    Pragmaticamente, etichettare quale connettore SATA va a quale unità nel proprio desktop può essere la soluzione più rapida e semplice, mentre cambiare il modo in cui il sistema si avvia e recuperare da un probabile errore di avvio è, probabilmente, il peggior spreco di tempo. Ma se ci riuscite per 50 programmatori che pensano che inserire un disco in più non sia un problema degno di essere disturbato, almeno non mettete alla prova i limiti della vostra fortuna e fate in modo che i loro dischi di avvio iniziali siano tutti visti da grub come hd0 e il sistema come sda.

  • Etichette per gestire le proprie unità e partizioni nel proprio desktop o in un piccolo ambiente (un salotto di una casa piena di ingegneri software che chiamano stranamente questo posto "ufficio di avvio"). Se si estrae un'unità fisica dalla macchina di qualcuno, si sa da dove proviene se si usano le etichette in modo coerente.

    Se lsblk(8) dice LABEL=bubba-bootsi sa che è stato estratto dalla macchina chiamata bubba; inoltre, bubba-boot si muove sulla mia lingua molto più facilmente di 6864c4ea-f9b9-46db-b875-4d7fc2981007 che, per i miei gusti viziati, è un vero spaccamascella. L'unicità delle etichette è ora a carico dell'utente, ma ciò che si ottiene in cambio è la significatività dell'etichetta.

  • /dev-basato su link Quando si comanda un battaglione di macchine virtuali a vita relativamente breve e a bassa manutenzione, che sono figli della stessa immagine, non si può scommettere il proprio stipendio settimanale sul fatto che tutti i loro UUID siano all'altezza della promessa UU. Qualsiasi sano di mente VM, sia esso Vyper-H sul proprio server fisico o Kugel Cloud o qualsiasi altra cosa, non si dovrà mai chiamare il proprio disco di avvio sde, e il secondo e unico altro sdc². In una macchina fisica, invece, è possibile ottenere facilmente la stessa disposizione collegando in modo creativo i cavi SATA.

    Sto divagando, ma in questo scenario, seguo la stessa strada con la cosiddetta denominazione "coerente" dell'interfaccia Ethernet: la disabilito nelle macchine virtuali. Non fraintendetemi, la denominazione è davvero coerente, a patto che la NIC inserita nello slot PCI 4 non passi improvvisamente allo slot 5 per un suo capriccio mentre non state guardando (o magari anche mentre siete in giro per la città).e; Le NIC non hanno alcuna vergogna). Purtroppo, nell'ambiente del "battaglione di macchine virtuali" è così. In questo caso, controintuitivamente, eth0 è più coerente rispetto a enp0s4f6. Il fornitore di macchine virtuali non ha promesso di mettere sempre la sua NIC virtuale numero 1 nello slot 4 del bus PCI 0 (e nessuna delle tre entità citate è fisicamente reale), e che sarà sempre la funzione 6. Ma si può fare affidamento sul fatto che la prima interfaccia vada prima della seconda, considerando che normalmente hanno lo stesso modulo driver, comunemente della famiglia virtio (e se la prima NIC non è sempre eth0si applica comunque la stessa nota²).


¹ In senso figurato, ovviamente. Faccio questo mestiere da troppo tempo per averne ancora.
² Se lo facessero, prenderei seriamente in considerazione di scappare urlando da loro cambiare il fornitore o il software dell'hypervisor della VM.

Ti mostriamo commenti e punteggi

Se puoi, puoi lasciare un commento su ciò che ti è piaciuto di questo post.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.