Perché la tabella degli inode di solito non è ridimensionabile?

I file system Unix di solito hanno una tabella di inode e il numero di voci in questa tabella è solitamente fissato al momento della creazione del file system. Questo a volte porta le persone con molto spazio su disco a ricevere messaggi di errore confusi su nessuno spazio libero, e anche dopo aver capito qual è il problema, non esiste una soluzione facile per cosa fare al riguardo.

Ma sembra (per me) che sarebbe molto desiderabile evitare tutto questo casino allocando gli inode su richiesta, in modo completamente trasparente per gli utenti e gli amministratori di sistema. Se ti piacciono gli hack carini, potresti persino fare in modo che la tabella degli inode sia un file, e quindi riutilizzare il codice che hai già che trova spazio libero sul disco. Se sei fortunato, potresti persino finire con gli inode vicino ai file stessi, senza cercare esplicitamente di ottenere questo risultato.

Ma nessuno (che io conosca) lo fa davvero, quindi probabilmente c'è un problema che mi manca. Qualche idea di cosa potrebbe essere?

filesystems inode

— Mark VY
fonte

Hai appena reinventato la directory dei file master e l'indice dei file-11 in VMS, il precursore della tabella dei file master in NTFS.

— JdeBP,

Ho reinventato il precursore della MFT? Freddo!

— Mark VY

Risposte:

Supponiamo che tu abbia trasformato la tabella degli inode in un file; quindi la domanda successiva è ... dove memorizzi le informazioni su quel file? Avresti quindi bisogno di inode "reali" e inode "estese", come una tabella delle partizioni MS-DOS. Dato, ne avresti bisogno solo uno (o forse alcuni - ad esempio, per avere anche il tuo diario come file). Ma in realtà avresti casi speciali, codice diverso. Qualsiasi corruzione a quel file sarebbe anche disastrosa. E considera che, prima del journaling, era comune per i file che venivano scritti, ad esempio, quando il potere usciva per essere gravemente danneggiato. Le operazioni sui file dovrebbero essere molto più robuste rispetto a interruzioni di corrente / crash / ecc. di quanto non fossero su, ad esempio ext2.

I filesystem Unix tradizionali hanno trovato una soluzione più semplice (e più robusta): inserire un blocco inode (o gruppo di blocchi) ogni X blocchi. Quindi li trovi per semplice aritmetica. Naturalmente, non è possibile aggiungerne altri (senza ristrutturare l'intero filesystem). E anche se perdi / corrompi il blocco di inode a cui stavi scrivendo in caso di interruzione dell'alimentazione, si perdono solo pochi inode - molto meglio di una parte sostanziale del filesystem.

I design più moderni usano cose come le varianti B-tree . I filesystem moderni come btrfs, XFS e ZFS non soffrono di limiti di inode.

— derobert
fonte

Quando dici "non soffrire di limiti di inode", significa che i nuovi inode sono allocati completamente dietro le quinte o qualcuno deve eseguire un comando come "espandi-tabella-ora-per favore"?

— Mark VY

@MarkVY completamente dietro le quinte (se gli inode sono davvero usati).

— derobert,

Ok, quindi la mia conoscenza è apparentemente molto indietro rispetto ai tempi. Grazie per la risposta dettagliata Non ho mai pensato a cosa sarebbe successo in caso di perdita di potenza o simili. Quindi il mio hack carino è piuttosto pericoloso a meno che "append to file" non sia già un'operazione atomica nel file system. Che affermi fosse piuttosto raro ai vecchi tempi.

— Mark VY

Mi ricordo XFS e Btrfs molto di tanto in tanto soffre di lieve corruzione del filesystem - ZFS troppo? Non è un rischio per alcuni, ma potrebbe essere un rischio per dati importanti e il costo dell'allocazione dinamica. Per XFS in questo negozio, il suo problema di rottura era la totale incapacità di ridurre un filesystem con qualsiasi mezzo.

— user2066657

Btrfs potrebbe non soffrire di limiti di inode, ma soffre di un errore completamente diverso che causa sintomi di confusione simili (in sostanza, esaurisce lo spazio dei metadati pur avendo a disposizione un sacco di spazio dati, a causa dell'uso inefficiente di gruppi di blocchi). Ciò non solo causa segnalazioni di errori del disco pieno quando dfsegnala molto spazio disponibile, ma non può essere corretto eliminando i file perché l'eliminazione di un file richiede l'allocazione dello spazio dei metadati.

— Segna il

Molti filesystem hanno una tabella di inode allocabile dinamicamente (o il suo equivalente morale) (XFS, BTRFS, ZFS, VxFS ...)

L'UFS Unix originale aveva però degli inode che erano corretti al momento della creazione del filesystem e i filesystem da esso derivati (Linux EXT, Solaris UFS) spesso continuavano lo schema. È robusto e più semplice da implementare. Tanti casi d'uso sono adatti, che progettare un nuovo filesystem solo per evitare che un problema non sia facile da giustificare.

— BowlOfRed
fonte

Tuttavia, molti progressi nell'informatica sono stati fatti da persone che risolvono problemi non facili da giustificare.

— user253751

Ma anche molti progressi nelle soluzioni non facili da risolvere :) I primi file system "complessi" - NTFS NT NT, reiserfs - avevano un modo di fallire catastroficamente QUANDO fallivano ....

— rackandboneman il

Esistono filesystem che allocano dinamicamente gli inode: dalla cima della mia testa, almeno Veritas VxFS (= il filesystem predefinito di HP-UX e una delle scelte disponibili su Solaris) e XFS (il tipo di filesystem standard su RHEL 7) funzionano quel modo. Anche Btrfs e IBM JFS.

— TELCOM
fonte