Quedarse sin memoria ejecutando fsck en grandes sistemas de archivos

Cuido una vieja caja Linux de Debian (ejecutando etch) con solo 512 MB de RAM, pero con mucho almacenamiento externo conectado. Un sistema de archivos ext3 tiene un tamaño de 2.7 TB y fsck no puede verificarlo porque se queda sin memoria, con un error como este:

   Error al asignar la matriz de bloque de directorio: error de asignación de memoria
   e2fsck: abortado

He agregado una partición de intercambio de 4 GB y todavía no se completa, pero este es un kernel de 32 bits, por lo que no espero que agregar más ayude.

Además de arrancar en un kernel de 64 bits, ¿hay alguna otra forma de hacer que fsck complete su comprobación?

Un núcleo de 64 bits y grandes cantidades de RAM permitirán que el fsck termine bien y rápido. Alternativamente, ahora hay una opción en e2fsck que le indicará que almacene todos sus resultados intermedios en un directorio en lugar de en la RAM, lo que ayuda muchísimo. Crea /etc/e2fsck.confcon los siguientes contenidos:

[scratch_files]
directory = /var/cache/e2fsck

(Y, obviamente, asegúrese de que ese directorio exista y esté en una partición con unos pocos GB de espacio libre). e2fsck ejecutará SLLOOOOWWWWWWW, pero al menos se completará.

Por supuesto, esto no funcionará con el FS raíz, pero si tiene un intercambio, entonces ya no podrá montar el FS raíz.

Terminé probando lo que sugirió womble; Aquí hay algunos detalles más que pueden ser útiles si, como yo, no has visto esta nueva funcionalidad en e2fsck antes.

La opción de configuración "scratch_files" para e2fsck estuvo disponible en algún momento del período de la versión 1.40.x. (En nuestro caso, tuvimos que actualizar a la última distribución de Debian para obtener esta funcionalidad).

Además de la opción "directorio = / var / caché / e2fsk" sugerida, hay algunas opciones de configuración adicionales para ajustar cómo se usa el almacenamiento de archivos de memoria virtual. Usé "dirinfo = false", ya que el sistema de archivos tenía una gran cantidad de archivos, pero no una gran cantidad de directorios. Si la situación se invirtiera, la opción "icount" sería apropiada. Todas estas opciones se documentaron en la página de manual de e2fsck.conf.

Por cierto, Ted T'so escribió sobre estas opciones en este hilo .

Encontré que e2fsck funcionaba extremadamente lento, mucho más de lo previsto por Ted. Funcionaba al 99.9% de la utilización de la CPU la mayor parte del tiempo (en un procesador antiguo extremadamente lento), lo que sugiere que almacenar estas estructuras de datos en el disco en lugar de la memoria no fue la causa principal de la desaceleración. Puede ser que algo más sobre lo que estaba almacenado en el sistema de archivos hizo que e2fsck fuera particularmente lento. Al final, he abandonado la verificación del sistema de archivos por ahora; el sistema de archivos debía ser revisado, pero no tenía errores (hasta donde yo sé), así que voy a hacer los arreglos para verificarlo en un momento más conveniente cuando podamos permitirnos una interrupción de una semana.