Superblocchi del filesystem e loro copie di backup

3

Mi piacerebbe capire come i filesystem (moderni) sono implementati e avere problemi a comprendere appieno i superblocchi e i loro backup. Faccio riferimento a ext4 e btrfs, ma le domande possono riguardare anche altri file system.

Ext4 memorizza un paio di superblocchi (il mio fs, ad esempio, ha un SB principale e sette backup). Capisco che, dal momento che il superblocco definisce caratteristiche importanti del filesystem, un backup inline ha senso. Ma non capisco perché così tanti backup, quindi:

  • Perché archiviare così tanti superblocchi? Qual è il vantaggio di avere 7 SB di backup rispetto ad appena uno?

Secondo documentazione ext4 ext4 memorizza un "tempo di scrittura" all'interno dell'SB (ultima scrittura da epoca). Ciò implicherebbe che ogni operazione di scrittura consiste anche in una scrittura sull'SB. Dato il mio sistema, con 7 SB di backup, ogni transazione di scrittura consisterebbe in 8 scritture SB. Sembra una quantità ridicola di scritture di metadati non sequenziali per una singola transazione, che portano alla domanda:

  • Sono sicuro che su SBs ext4 sono scritti così spesso?

Le stesse domande si applicano fondamentalmente a btrfs dove gli SB sono distribuiti tra blocchi di indirizzi statici (blocco primario a 0x10000) e solo in modalità SSD (a causa di problemi di livellamento dell'usura) ne viene scritto uno solo per commit.

  • C'è un vantaggio per btrfs per memorizzare il superblocco primario a 0x10000 invece di 0x0?

La documentazione di btrfs afferma inoltre: Si noti che btrfs riconosce solo i dischi con un superblocco 0x10000 valido; altrimenti, ci sarebbe confusione con altri filesystem. Questo è ancora più confuso poiché un SB rotto a 0x10000 porterebbe a un filesystem non valido, anche se ci sono altri SB validi in altre posizioni.

  • In che modo btrfs beneficia dei backup superblocchi, se il filesystem non è valido su un superblocco primario non funzionante?
posta grasbueschel 23.10.2014 - 21:28
fonte

1 risposta

5

Si tratta di un'immersione un po 'profonda nelle specifiche strutture sottostanti dei filesystem, che sono molto complicate e idiosincratiche. Ma qui va ...

Per prima cosa, i superblocchi non sono una cosa. Sono diversi, dal filesystem al filesystem, in quali informazioni contengono. I due filesystem di cui parli, extN e btrfs, sono molto evoluti e non tutti simili a nonni Unix. E la maggior parte degli Unix nonni come AIX, HP-UX, IRIX e Solaris sono almeno lontanissimi dal BSD "Fast File System" e dai file system Unix Nth Edition originali.

Ma in tutte le implementazioni che ho visto, le diverse varianti sui superblocchi possono trovarsi nella parte superiore della gerarchia dei metadati del filesystem, ma sono non i blocchi di metadati primari per il file system, né la struttura dei dati che viene più spesso aggiornata. Ad esempio, non vengono aggiornati ogni scrittura, nemmeno ogni aggiornamento di metadati o modifica di directory. La ragione per cui sono così moltiplicate / ben protette è che, stando in cima alla struttura del file system, definiscono i parametri del filesystem (alcuni dei quali sono semanticamente critici per il corretto funzionamento) e collegano tutti gli altri strutture di metadati. Senza di essi, anche trovare tutte le altre strutture di metadati sarebbe difficile, e molto meno ottenere un'interoperabilità perfetta, come originariamente intesa.

Nel corso degli anni, la capacità degli strumenti di verifica e riparazione del filesystem ( fsck è il grande bisnonno di tutti) per riparare da guasti catastrofici (come "superblock loss") è migliorata. Ma è brutto, lento ed euristico (cioè potenzialmente imperfetto = possibile perdita di dati) su quasi tutti. E le cose che tutte le implementazioni Unix si sono sforzate nel corso degli anni includono maggiore affidabilità, storage più robusto e tempi di avvio più veloci). Avere un faticoso processo di check-and-repair è un impedimento per tutti. Quindi il passaggio alla replica N-way.

Poiché i superblocchi (o più in generale, tutti i blocchi / strutture dati che definiscono il filesystem nel suo complesso) non sono i metadati più attivi ("i più") del sistema (solo il livello più alto) e perché la loro perdita è così dannosi, i progettisti concludono che possiamo permetterci la duplicazione a 2 o più vie. Tendono ad avere i dati scaricati su disco solo periodicamente (ad esempio ogni 30 secondi). Pertanto il loro sovraccarico di prestazioni / aggiornamento è minimo.

Non ho usato btrfs o ho tentato di ripristinarlo da un errore, quindi non ho particolari informazioni sulle sue peculiari restrizioni sul posizionamento di superblocchi, o quali particolari vincoli di livellamento del carico sono tipicamente abilitati per il funzionamento SSD. Ma come altri progetti di filesystem, il suo strumento di gestione ( btrfsck ) ha un'opzione specifica ( -u ) per specificare manualmente l'uso di un superblocco secondario o terziario. In extfs , l'opzione corrispondente è -b . Ogni altro file system Unix ha controlli / comandi altrettanto idiosincratici per le procedure di riparazione nel suo strumento corrispondente.

    
risposta data 23.10.2014 - 22:43
fonte