Esaurire la memoria eseguendo fsck su filesystem di grandi dimensioni

Mi occupo di un vecchio box Debian per Linux (con etch) con solo 512 MB di RAM, ma molta memoria esterna collegata. Un filesystem ext3 ha una dimensione di 2,7 TB e fsck non può verificarlo, perché ha esaurito la memoria, con un errore come questo:

   Errore nell'allocazione dell'array di blocchi di directory: allocazione della memoria non riuscita
   e2fsck: interrotto

Ho aggiunto una partizione di swap da 4 GB e non viene ancora completata, ma si tratta di un kernel a 32 bit, quindi non mi aspetto che l'aggiunta di altri aiuti.

Oltre all'avvio in un kernel a 64 bit, ci sono altri modi per far sì che fsck completi il ​​suo controllo?

Un kernel a 64 bit e grandi quantità di RAM consentiranno a fsck di terminare in modo piacevole e veloce. In alternativa, ora c'è un'opzione in e2fsck che gli dirà di archiviare tutti i suoi risultati intermedi in una directory anziché in RAM, il che aiuta immensamente. Crea /etc/e2fsck.confcon i seguenti contenuti:

[scratch_files]
directory = /var/cache/e2fsck

(E, ovviamente, assicurati che la directory esista e si trovi su una partizione con pochi GB di spazio libero). e2fsck eseguirà SLLOOOOWWWWWWW, ma almeno sarà completo.

Ovviamente, questo non funzionerà con il root FS, ma se hai lo swap allora stai comunque montando il root FS.

Ho finito per provare ciò che suggeriva il womble; ecco alcuni dettagli che potrebbero essere utili se, come me, non hai mai visto questa nuova funzionalità in e2fsck prima.

L'opzione di configurazione "scratch_files" per e2fsck è diventata disponibile nel periodo della versione 1.40.x. (Nel nostro caso, abbiamo dovuto aggiornare all'ultima distribuzione Debian per ottenere questa funzionalità.)

Oltre all'opzione "directory = / var / cache / e2fsk" che è stata suggerita, ci sono alcune ulteriori opzioni di configurazione per ottimizzare il modo in cui viene utilizzato l'archiviazione dei file di memoria virtuale. Ho usato "dirinfo = false", poiché il filesystem aveva un gran numero di file, ma non un numero così elevato di directory. Se la situazione fosse invertita, l'opzione "icount" sarebbe appropriata. Queste opzioni sono state tutte documentate nella pagina man di e2fsck.conf.

A proposito, Ted T'so ha scritto di queste opzioni in questo thread .

Ho scoperto che e2fsck correva molto lentamente, molto più di quanto previsto da Ted. Funzionava al 99,9% di utilizzo della CPU per la maggior parte del tempo (su un vecchio processore estremamente lento), il che suggerisce che l'archiviazione di queste strutture di dati su disco anziché su memoria non fosse la causa principale del rallentamento. Potrebbe essere che qualcos'altro su ciò che è stato archiviato nel filesystem abbia reso particolarmente lento e2fsck. Alla fine, ho abbandonato il controllo del filesystem per ora; il filesystem doveva essere verificato, ma non presentava errori (per quanto ne so), quindi organizzerò il controllo in un momento più conveniente quando potremo permetterci un'interruzione di una settimana.