max archivos por directorio en ext4

Administro una aplicación que contiene un almacén de archivos en el que todos los archivos se almacenan con los nombres de archivo iguales a sus sumas md5. Todos los archivos se almacenan en un directorio. Actualmente hay miles, pero pronto deberían haber millones de archivos en el servidor. El servidor actual ejecuta Ubuntu 11.10 en un sistema de archivos ext4.

Alguien me dijo que no es aconsejable poner muchos archivos en un directorio, ya que esto creará un aumento significativo en el tiempo de búsqueda y la confiabilidad (tenía una historia sobre los archivos máximos que un único directorio podría señalar, lo que resulta en una gran lista vinculada). En su lugar, sugirió crear subdirectorios con, por ejemplo, subcadenas del nombre del archivo. Sin embargo, esto hará que algunas cosas en mi aplicación sean mucho más engorrosas.

¿Sigue siendo cierto o los sistemas de archivos modernos (por ejemplo, ext4) tienen formas más eficientes de lidiar con esto y escalar naturalmente? Wikipedia tiene algunos detalles sobre los sistemas de archivos, pero en realidad no dice nada sobre los archivos máximos por directorio, o los tiempos de búsqueda.

Los ext3sistemas de archivos y posteriores son compatibles con la indexación de directorio de árbol B hash . Esto escala muy bien siempre que las únicas operaciones que realice sean agregar, eliminar y acceder por nombre. Sin embargo, aún recomendaría desglosar los directorios. De lo contrario, se crea una trampa peligrosa para herramientas ( updatedb, ls, du, etc.) que realizan otras operaciones en directorios que pueden estallar si el directorio tiene demasiadas entradas.

El núcleo del problema está cavando a través del inodo de directorio para el archivo que desea. Algunos sistemas de archivos lo hacen mejor que otros. Algunos escalan cerca de los miles de millones, pero si solo tiene ... 20K archivos para llegar a esos archivos es notablemente más rápido. Además, los grandes recuentos de archivos crean problemas para ciertas herramientas y pueden hacer que la copia de seguridad / restauración sea un problema mucho más difícil como resultado.

Como sucede, me encontré exactamente con el mismo problema en nuestro propio desarrollo (md5sum como nombre de archivo, escalado del mismo). Lo que les recomendé a nuestros desarrolladores es cortar la cadena en pedazos. Fueron con grupos de 4, pero en el sistema de archivos en el que estábamos en ese momento, incluso muchos resultarían problemáticos desde una perspectiva de rendimiento, por lo que terminaron dividiéndose en un grupo de 3 para los primeros 6 trillizos y dejando el resto como el nombre del archivo en el directorio del terminal.

Grupo de 4: 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
Grupo de 3:497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt

Esto tiene la ventaja de mantener pequeños los tamaños de directorio, y dado que MD5sum es bastante aleatorio, creará árboles de directorio equilibrados. Es poco probable que ese último directorio obtenga más que unos pocos archivos. Y no fue tan difícil trabajar en nuestro código. Trabajamos con proyectos de archivos multimillonarios, por lo que el escalado fue muy importante para nosotros.

Los sistemas de archivos modernos manejan directorios muy grandes muy bien, incluso para millones de archivos. Pero las herramientas convencionales no. Por ejemplo, enumerar un directorio tan grande con "ls" llevaría bastante tiempo ya que normalmente leería todo el directorio y lo ordenaría (aunque puede usar ls -f para evitar la ordenación). No comenzaría a mostrar archivos hasta que se hayan leído todos. La división de los nombres ayuda en algunos casos, pero no en todos (por ejemplo, la replicación de rsync aún podría necesitar recopilar todo el árbol de nombres).

¿Puedo sugerir usar una base de datos SQL en su lugar? Esto probablemente transformaría esta debilidad percibida en su aplicación en una fortaleza.