Prefacio: no le mandé un signo de admiración en el título para hacerlo mas llamativo. El mensaje de error propiamente dicho –cuando se manifiesta y si estás leyendo esto por que te pasó va mi mas sentido pésame-, citado literalmente dice «Directory index full!» así como le leés, provocador, quilombero y gritón.

Puto el developer que dió por sentado que cualquier usuario de Linux de a pié va a saber que carajos es el directory index y puto el que le agregó un signo de exclamación al final. Mangas de hippies melodramáticos. Como si fuera tan grave.

No importa. Si estás leyendo esto por que llegaste desde Google, cosa que dudo por que este blog no rankea y por eso no me lee nadie, estás en el mismo bote en donde ya estuve muchas veces y seguramente habrás dicho: uh? WTF?

Si no llegaste desde Google, posiblemente quieras cerrar la tab del navegador e irte a hacer otra cosa. Lo que sigue no le importa a nadie mas que a los pocos infelices que nos topamos alguna vez con este error de mierda.

Ahora si, vamos a lo que nos importa a los miserables:

dir_index suena a nombre bastante autoexplicativo y nunca ahondé en detalles acerca del principio de funcionamiento de la opción por que con lo que sé al respecto me basta y en cierto punto se pone medio esotérico, pero acá va:

• ext3 y ext4, los sistemas archivos por defecto de todas las distribuciones de Linux vigentes incorporan dir_index por defecto en el formateo que realizan durante la instalación, por que en determinadas circunstancias sirve y acelera procesos dejando descansar al disco rígido un poquito más y reduciendo los tiempos de acceso e I/O load.
• mkfs no incorpora dir_index por defecto y si lo querés tenés que empujarlo a mano durante el formateo: mkfs.ext4 -O dir_index /dev/sdCOSO
• También podés empujarselo de prepo al sistema de archivos al montarlo manualmente o desde el fstab agregando dir_index a las mount options.
• Todo aquello que se almacene en el filesystem y ocupe mas que un bloque (si no lo tuneaste durante el formateo, un bloque en ext3 o ext4 será siempre 4096 bytes, 4KB, cuatro cas). llevará asociada una entry en algo que se llama HTree en el dir_index y que no sé que mierda es ni me importa pero es en definitiva el quid de la cuestión.
• Lo que tiene de bueno lo tiene de malo: al parecer se llena tiene un tope de capacidad, o no existiría si no el mensaje de error.
• Lo que tiene de bruto, lo tiene de bruto: crashea miserablemente.
• Si no sabés los que es y lo que hace dir_index, seguramente te convenga tenerlo activado por que suma.

 

Sabiendo todo lo anterior acá va la parte más curiosa, es decir: cómo se arregla.

Ya sé, lo primero que pensaste cuando encontraste en tu syslog que el dir_index se llenó luego de que la tal o cual aplicación te crasheó miserablemente fue: Uy, puta madre, se me llenó el disco!

Luego fuiste y viste que nada, falsa alarma, que no se te llenó el disco. Si sos usuario heavy de Linux automáticamente pensaste: Uy! Puta madre, se me acabaron los inodos, pero no, tampoco te quedaste sin inodes. Tenés inodes como para donarle al caritas parroquial de tu barrio y que te sigan alcanzando para el resto de tu vida y la de toda tu progenie. (Pero que conste que bien te podrías haber quedado sin inodos también y de hecho me ha pasado varias veces por idiota).

 

Va a ser que no. Que cuanto se te hace mierda el filesystem por la misma corrupción que van generando los años de uptime sin reboot o los malos apagados por que no tenes UPS, y justo se trata de alguna partición en donde alojas un par de billones de archivitos, hay una altísima posibilidad de que te encuentres con este mensaje de error.

 

Primero lo mas obvio. umount y fsck:

fsck -y -f /dev/sdCOSO – donde -y es para que no te pregunte nada antes de romper todo y que tengas que reinstalar o darle explicaciones al propietario de la data almacenada.

Apuesto hasta tres pesos a que con solamente eso ya se arregla el problema. Por si no es obvio: tenés que ser root, la partición no puede estar montada o de nuevo, rompés todo y no podés hacer fsck sobre la partición raíz (/, root, rut) sin reiniciar. Como desmontar, programar un fsck, reiniciar y etc si fuera necesario están como 200 metros mas abajo del alcance de esta guía.

 

Si con eso no se arregló, apagá dir index, (se puede apagar con el Filesystem online y montado) y remontá sin -o dir_index:

tune2fs -O ^dir_index /dev/sdCOSO

Luego ejecutá la aplicación que crashea y fijate si así se arregló, en tal caso repetí el proceso a la inversa: encendé, desmontá, remontá y vení a darme las gracias.

 

Si no se arregló, apagale el journaling al filesystem:

tune2fs -O ^has_journal /dev/sdCOSO

Luego fsck, luego se lo encendés nuevamente y luego si, remontás, ves que se arregló, venís y me das las gracias.

 

Por último: Como comprobar si tenés dir_index o journaling activado:

tune2fs -l /dev/sdCOSO | grep features