it-swarm-es.com

Quedarse sin memoria ejecutando fsck en sistemas de archivos grandes

Cuido una vieja caja de Debian Linux (ejecutando etch) con solo 512 MB de RAM, pero una gran cantidad de almacenamiento externo adjunto. 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 bloques de directorio: Error en la asignación de memoria 
 E2fsck: abortado 

Agregué 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 otras formas de hacer que fsck complete su verificación?

13
TimB

Un kernel de 64 bits y grandes cantidades de RAM permitirán que el fsck finalice bien y rápido. Alternativamente, ahora hay una opción en e2fsck que le dirá que almacene todos sus resultados intermedios en un directorio en lugar de en RAM, lo que ayuda enormemente. Cree /etc/e2fsck.conf con el siguiente contenido:

[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 swap, entonces ya no ha montado la raíz FS de todos modos.

12
womble

Terminé probando lo que sugirió womble; Aquí hay algunos detalles más que pueden ser útiles si, como yo, no ha 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/cache/e2fsk" que se sugirió, hay algunas opciones de configuración adicionales para ajustar cómo se usa el almacenamiento de archivos temporales. 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 .

Descubrí que e2fsck se estaba ejecutando extremadamente lento, mucho más de lo que predijo 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 ralentización. Podría ser que algo más sobre lo que estaba almacenado en el sistema de archivos hiciera 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 arreglos para revisarlo en un momento más conveniente cuando podamos permitirnos tener una interrupción de una semana.

6
TimB