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

Molte volte, specialmente quando si scherza con i bootloader, vedrò i numeri numerici di unità e partizioni. Ad esempio, a mio /boot/grub/grub.cfgavviso set root='hd0,gpt2', le mie voci di avvio UEFI spesso fanno riferimento a numeri di unità / partizioni e sembra sorgere in quasi tutti i contesti che riguardano i bootloader.

Ora che abbiamo UUID e PARTUUID, indirizzare le partizioni in questo modo sembra incredibilmente instabile (a proposito, le unità non sono garantite per essere montate sempre nello stesso ordine, un utente può spostare l'ordine delle unità da collegare al loro mobo, ecc.)

Le mie domande quindi sono duplici:

1. Questo schema di indirizzamento è instabile come ho indicato sopra? Mi manca qualcosa nello standard che significa che questo schema è molto più affidabile di quanto mi aspetto, o questo schema di indirizzamento renderà davvero il tuo sistema non avviabile (fino a quando non aggiusti almeno le voci di avvio) come risultato del riconoscimento delle tue unità in un ordine diverso o collegandoli a slot diversi sulla scheda madre?

2. Se la risposta alla domanda precedente è sì, perché questo schema di indirizzamento continua a essere utilizzato? L'uso di UUID o PARTUUID per tutto sarebbe molto più stabile e coerente?

Lo schema di numerazione semplice non è effettivamente utilizzato nei sistemi recenti (con "recente" Ubuntu 9 e versioni successive, anche altre distribuzioni potrebbero essersi adattate anche in quell'epoca).
Hai ragione nell'osservare che la partizione di root è impostata con il semplice schema di numerazione. Ma questa è solo un'impostazione predefinita o fallback che di solito viene sovrascritta con il comando immediatamente successivo, come ad esempio:

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

Questo seleziona la partizione di root in base all'UUID del file system.

In pratica, lo schema di numerazione normale è generalmente stabile (purché non vi siano modifiche hardware). L'unica istanza che ho osservato per la numerazione non prevedibile era il sistema con molte unità USB che erano enumerate in base a un modello di servizio primo arrivato e quindi emulate come unità IDE. Nessuno di questi processi è intrinsecamente caotico, quindi presumo un problema nell'implementazione del BIOS di quel particolare sistema.

Nota: "partizione root" in questo contesto indica la partizione da cui eseguire l'avvio, potrebbe essere diversa dalla partizione contenente il "root aka. / File system".

A rigor di termini, UUID non si rivolge affatto.

L'indirizzamento è molto, molto semplice: leggi il settore X del settore Y - oppure. Leggi l'indirizzo di memoria Z - oppure. L'indirizzamento è semplice, veloce, non lascia molto spazio all'interpretazione ed è ovunque.

UUID non si sta indirizzando. Invece cerca, trova, a volte aspetta che appaiano i dispositivi e capisce anche i filesystem (★). E a seconda del numero di dispositivi disponibili, potrebbe richiedere molto tempo. E una volta trovato, torniamo a indirizzarlo regolarmente.

In GRUB, questo si chiama search(★★) ed è disponibile solo quando GRUB ha già sviluppato le ali (la ricerca è un modulo, come ogni file system che supporta, quindi disponibile solo dopo aver caricato 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 .

Passa attraverso tutti i dispositivi a blocchi, li riattiva dallo standby, legge i dati e il risultato potrebbe anche essere casuale se l'UUID non è univoco come dovrebbe essere (dopo un ddincidente o simili) o 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 dovresti usarli ovunque se disponibili, specialmente quando l'indirizzamento tradizionale è destinato a fallire perché l'ordine delle unità è casuale in Linux; ma capisci che la complessità è al di sopra e al di là di ciò che il semplice indirizzamento dovrebbe fare. E soprattutto nelle primissime fasi dei bootloader, potrebbe non essere ancora un'opzione. L'indirizzamento viene prima, le ali crescenti arrivano dopo.

Per il bootloader, potrebbe semplicemente non essere necessario compiere lo sforzo (non tutti i bootloader supportano una vasta gamma di filesystem come GRUB). Se hd0è garantito che sia "il disco da cui abbiamo avviato" a causa di circostanze (fornite dal BIOS), e quindi se si possono escludere problemi di ordine casuale dell'unità, potrebbe non essere necessario passare attraverso un elenco potenzialmente enorme di altre partizioni in cerca UUID.

Se sei abbastanza sicuro nella tua configurazione da dire che hd0,gpt2è quello che vuoi, e deve essere, e non può essere altrimenti, allora non c'è niente di sbagliato nell'usarlo in quel modo. A volte, l'indirizzamento semplice e chiaro funziona bene.

(★) In precedenza l'ho spiegato per ETICHETTE qui ...

Non esiste uno standard generico per le etichette, è tutto lavorato a mano, vedere ad esempio questa implementazione di formati di superblocchi in util-linux . Se inventi un nuovo file system domani, anche se ha un'etichetta, non verrà visualizzato fino a quando non verrà aggiunto il supporto.

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

(★★) In realtà, GRUB searchha --hintun'opzione e ... ora non ho controllato il codice sorgente e non è nemmeno documentato nel loro manuale, ma un'opzione del genere avrebbe senso darti il ​​meglio di entrambi i mondi: il suggerimento dovrebbe dire searchdi controllare prima quella partizione , e se l'UUID corrisponde come previsto, ha identificato il dispositivo con il minimo sforzo e, se non corrisponde, tornerà comunque alla ricerca completa per far funzionare le cose in qualche modo .

Inoltre, gli UUID precedentemente trovati tendono ad essere memorizzati nella cache, quindi non deve passare attraverso tutti i dispositivi ancora e ancora e ancora e ancora - e anche questo funziona alla grande, a condizione che l'UUID che stai cercando effettivamente esiste da qualche parte per farlo nella cache in primo luogo.

Inoltre, non dimenticare le etichette. Non sono unici come gli UUID, ma molto più informativi e rendono leggibile il tuo umano. Se è il tuo desktop o una piccola azienda, in altre parole, stai gestendo da poche a poche decine di unità, potresti preferire le etichette agli UUID.

Riflettendo sull'eccellente risposta di @frostschutz alla tua domanda, uno scenario in cui preferiresti probabilmente il "classico" indirizzamento dei collegamenti dei dispositivi è la configurazione della VM, specialmente nei cloud VM-for-Hire (abbreviati, confusi, "IaaS"). Supponiamo di voler personalizzare un'immagine Ubunzima 04.18 . Si crea una VM (usa e getta) con 2 dischi: uno sarà l'unità di sistema (usa e getta) e il secondo quello che si monterà e si personalizzerà. Presumibilmente, si monta anche la sua partizione di avvio UEFI, se si desidera eseguire il grub di un nuovo grub sul nuovo disco. Supponendo che abbiate scelto i punti di montaggio per le partizioni target in basso /mnt, appare la tabella di montaggio desiderata

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

Quindi crei 2 unità identiche dall'immagine esistente, fornita dal provider e pronta per il cloud, collegale a una nuova macchina virtuale e avviala. Naturalmente,

• Tutte le moderne distribuzioni del sistema operativo, la nostra immaginaria Ubunzima 04.18 non fa eccezione, si basano su supporti denominati UUID.
• Tutti i dischi rigidi implementati dalla stessa immagine hanno lo stesso UUID. Gli UUID sono unici, quindi cosa potrebbe andare storto?

Vedi già dove sta andando tutto.

La prima volta che si è avviato questo affrancatura, è stata scelta sda9come partizione di avvio EFI, ma Linux ha deciso di rimontarla sdb1come root FS:

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

E dal momento che il mio script di roll-out era abbastanza impreparato per questo, alla fine ho ottenuto un'immagine dud non avviabile, senza un singolo strumento che si lamenta nel registro durante il frankenbuild!

Ovviamente ho stampato la tabella di montaggio nei registri. E, naturalmente, il disordine è molto difficile da individuare, poiché mount (8) stampa i supporti nell'ordine a metà strada tra quello casuale e quello in cui sono stati montati i dispositivi, quindi non è sorprendente che non l'ho individuato immediatamente. E immagina, lo stesso copione (ma con dischi di immagini diverse) precedentemente funzionava liscio come il 15enne Glenfiddich. Indovina quante ore ho passato a pettinarmi¹ sul tronco cercando di capire il problema?

Non esistono regole rigide e veloci adatte a qualsiasi situazione, da un PC desktop a un Linux incorporato in un router, dal tuo telefono Android a un data center cloud. Una risposta SO dovrebbe essere obiettiva, e le mie esperienze o preferenze non lo sono. Quindi preferirei mostrare esempi di ragionamento logico quando seleziono tra diversi metodi di identificazione delle partizioni:

• Lascia perdere se non hai motivo di non farlo. Gli UUID sono i valori predefiniti per la maggior parte delle distro moderne. Se si tratta di aggiungere una seconda unità, provare quindi e decidere. È probabile che non avrai mai nemmeno bisogno di saperlo. Se il tuo sistema si avvia ancora e puoi vedere e partizionare il nuovo dispositivo, formattalo e aggiungilo a fstab (per UUID, per LABEL o per /devcollegamento, valgono le stesse considerazioni). È solo quando il tuo sistema rifiuta l'avvio dopo aver collegato l'unità aggiuntiva, quindi hai un problema (e forse cambiare l'ordine di avvio nel BIOS UEFI è la via più rapida).

  Pragmaticamente, etichettare quale connettore SATA va a quale unità sul proprio desktop può essere la soluzione più veloce e più semplice, mentre cambiare il modo in cui il sistema si avvia e il ripristino da un errore di avvio molto probabile è, senza dubbio, il peggior gobbler del tempo. Ma se lo gestisci per 50 programmatori che pensano che il lancio di un'unità aggiuntiva non sia un problema degno di disturbarti, almeno non testare i limiti della tua fortuna e assicurarti che le loro unità di avvio iniziali siano tutte viste da grub come hd0e il sistema come sda.

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

  Se lsblk (8) dice LABEL=bubba-boot, sai che è stato estratto dalla macchina chiamata bubba ; inoltre, lo stivale da bubba rotola sulla mia lingua molto più facilmente di 6864c4ea-f9b9-46db-b875-4d7fc2981007 , che, per il mio gusto viziato, è decisamente un gioco da ragazzi. Garantire che le etichette siano uniche ora si sposta su di te, ma ciò che ottieni in cambio è la significatività dell'etichetta.

• /dev-link basato su nomi quando si comanda un battaglione di VM relativamente di breve durata e di bassa manutenzione che generano la stessa immagine, e non si scommetterebbe sul salario settimanale che tutti i loro UUID mantengono la promessa dell'UU. Qualsiasi servizio VM sano , sia esso Vyper-H sul proprio server fisico o Kugel Cloud o altro, non deve mai chiamare l'unità di avvio sdee il secondo e l'unico altro sdc². In una macchina fisica, d'altra parte, puoi facilmente ottenere la stessa disposizione collegando in modo creativo cavi SATA.

  Sto divagando ora, ma in questo scenario, seguo lo stesso percorso con la cosiddetta denominazione di interfaccia Ethernet "coerente": disabilitala nelle macchine virtuali. Non fraintendetemi, la denominazione è davvero coerente fintanto che la scheda NIC inserita nello slot PCI 4 non salterà improvvisamente allo slot 5 per suo stesso capriccio mentre non state guardando (o forse anche mentre lo siete; NICs non avere vergogna di sorta). Sfortunatamente, nell'ambiente del "battaglione di VM" in realtà lo fanno. In questo caso, controintuitivamente, eth0è più coerente dienp0s4f6. Il provider di macchine virtuali non ha promesso di inserire sempre il proprio NIC virtuale numero 1 nello slot 4 sul bus PCI 0 (e nessuna delle 3 entità menzionate è fisicamente reale) e che sarà sempre la Funzione 6. Ma puoi piuttosto fanno molto affidamento sulla prima interfaccia che precede la seconda, considerando che normalmente hanno lo stesso modulo driver, comunemente della famiglia virtio (e se la prima scheda di rete non è sempre eth0, si applica sempre la stessa nota²).

  ---

¹ Ovviamente, figurato. Sono stato se questo business fosse troppo a lungo per esserne rimasto.
² Se lo facessero, prenderei seriamente in considerazione di scappare urlando da loro cambiando il provider o il software hypervisor VM.

Entrambi gli schemi possono essere mescolati e abbinati alla maggior parte delle distribuzioni di Linux.

Le conseguenze possono essere desiderabili o indesiderabili a seconda del caso d'uso - ad esempio, si potrebbe preferire lo schema più vecchio (e persino disabilitare gli hack di persistenza in stile udev) se la sostituzione a caldo di unità (hardware virtuale o hardware reale) senza dover modificare i file di configurazione è ricercato.

La risposta alla tua seconda domanda ("perché questo schema di indirizzamento continua a essere utilizzato?") È, suppongo, inerzia. Sì, è assolutamente possibile utilizzare solo UUID su dischi partizionati GPT. Puoi usare gli UUID invece dei /dev/xxxnomi in /etc/fstab. E ora che abbiamo la specifica delle partizioni rilevabili , in molti casi non è nemmeno più necessario specificare gli UUID, basta partizionare il disco con il tipo di partizione e le partizioni verranno raccolte automaticamente. Sulla mia macchina la root=voce manca del tutto dalla riga di comando del kernel.

E a proposito di boot loader: GRUB è per lo più superfluo sui moderni PC UEFI, nel senso che ha ben poco a che fare con il bootstrap della macchina. Oggi GRUB funziona semplicemente come un programma di selezione del kernel, per il quale sono disponibili alternative più semplici e migliori, come systemd-boot.