¿Hay un número máximo de inodos en un solo directorio?¿Número máximo de inodos en un directorio?
Tengo un directorio de más de 2 millones de archivos y no puedo obtener el comando ls para trabajar contra ese directorio. Entonces ahora me pregunto si he excedido el límite de inodos en Linux. ¿Hay un límite antes de un límite numérico de 2^64?
¿Puede obtener un conteo real de la cantidad de archivos? ¿Cae muy cerca de un límite de 2^n? ¿Podría simplemente quedarse sin memoria RAM para guardar todos los nombres de los archivos?
Sé que, al menos en Windows, el rendimiento del sistema de archivos bajaría dramáticamente a medida que aumentaba el número de archivos en la carpeta, pero pensé que Linux no sufría este problema, al menos si usabas un símbolo del sistema . Dios te ayudará si tratas de obtener algo como Nautilus para abrir una carpeta con tantos archivos.
También me pregunto de dónde vienen estos archivos. ¿Puedes calcular los nombres de los archivos programáticamente? Si ese es el caso, es posible que pueda escribir un pequeño programa para clasificarlos en varias subcarpetas. A menudo, enumerar el nombre de un archivo específico le otorgará acceso al intentar fallar al intentar buscar el nombre. Por ejemplo, tengo una carpeta en Windows con aproximadamente 85,000 archivos donde funciona esto.
Si esta técnica es exitosa, puede intentar encontrar la manera de hacer que este tipo sea permanente, incluso si solo está ejecutando este pequeño programa como un trabajo de cron. Funcionará especialmente bien si puede ordenar los archivos por fecha en alguna parte.
No. Los límites de inode son por sistema de archivos, y se deciden en el momento de creación del sistema de archivos. Podrías estar llegando a otro límite, o quizás 'ls' simplemente no funciona tan bien.
Prueba esto:
tune2fs -l /dev/DEVICE | grep -i inode
Se debe decirle todo tipo de información relacionada con i-nodo.
A menos que aparezca un mensaje de error, ls está trabajando pero muy lentamente. Puede intentar mirar sólo los primeros diez archivos como este:
ls -f | head -10
Si vas a tener que mirar los detalles de los archivos por un tiempo, puede ponerlos en un archivo primero. ¡Es probable que desee enviar la salida a un directorio diferente al que está enumerando en este momento!
ls > ~/lots-of-files.txt
Si quieres hacer algo para los archivos, puede utilizar xargs. Si decide escribir un script de algún tipo para hacer el trabajo, asegúrese de que el script procese la lista de archivos como una secuencia en lugar de todos a la vez. Aquí hay un ejemplo de mover todos los archivos.
ls | xargs -I thefilename mv thefilename ~/some/other/directory
Se puede combinar eso con la cabeza para mover un número más pequeño de los archivos.
ls | head -10000 | xargs -I x mv x /first/ten/thousand/files/go/here
probablemente Puede combinar ls | head en un script de shell para que dividir los archivos en un montón de directorios con un número manejable de archivos en cada una.
ls | head -10 no funciona para obtener un resultado inmediato, porque ls está ordenando, por lo que debe leer todo antes de poder imprimir nada. –
En ese caso, intente con: ls -f | head -10 –
df -i debe decirle la cantidad de inodos utilizados y gratis en el sistema de archivos.
Pruebe ls -U o ls -f.
ls, por defecto, ordena los archivos alfabéticamente. Si tienes 2 millones de archivos, ese tipo puede llevar mucho tiempo. Si ls -U (o quizás ls -f), los nombres de los archivos se imprimirán inmediatamente.
El tamaño máximo de directorio depende del sistema de archivos, y por lo tanto el límite exacto varía. Sin embargo, tener directorios muy grandes es una mala práctica.
Debería considerar hacer sus directorios más pequeños clasificando archivos en subdirectorios. Un esquema común es usar los dos primeros caracteres de un subdirectorio de primer nivel, de la siguiente manera:
${topdir}/aa/aardvark
${topdir}/ai/airplane
Esto funciona especialmente bien si se utiliza UUID GUID, o valores hash de contenido para poner nombres.
Según lo observado por Rob Adams, ls está ordenando los archivos antes de mostrarlos. Tenga en cuenta que si está utilizando NFS, el servidor NFS clasificará el directorio antes de enviarlo, y 2 millones de entradas pueden tomar más tiempo que el tiempo de espera de NFS. Eso hace que el directorio sea ineficaz a través de NFS, incluso con el indicador -f.
Esto puede ser cierto para otros sistemas de archivos de red también.
Si bien no existe un límite obligatorio para la cantidad de entradas en un directorio, es una buena práctica tener un límite para las entradas que anticipa.
Para NetBackup, los archivos binarios que analizan los directorios de los clientes realizan algún tipo de listado de tiempos de espera por la enorme cantidad de archivos en cada carpeta (aproximadamente un millón por carpeta, directorio de trabajo de SAP).
Mi solución fue (como Charles Duffy escribe en este hilo) reorganizar las carpetas en subcarpetas con menos archivos.
Otra opción es find:
find . -name * -exec somcommands {} \;
{} es la ruta absoluta.
La ventaja/desventaja es que los archivos se procesan uno detrás del otro.
find . -name * > ls.txt
imprimiría todos los nombres de archivo en ls.txt
find . -name * -exec ls -l {} \; > ls.txt
imprimiría todas ls forma de información para cada archivo en ls.txt
Tienes que incluir el wildchar entre comillas simples si no quieres que el shell lo expanda (¡puede ser bastante largo si hay más de 2 millones de archivos!) –
Debes aprender sobre el 'xargs' mando. Es mucho más eficiente que la opción -exec del comando find. –
@Didier Trosset, las nuevas versiones del estándar POSIX admiten 'find ... -exec {} +' (en lugar de '-exec {};'), que tiene una eficacia similar a xargs. –
Lo que golpea es un límite interno de ls. Aquí hay un artículo que lo explica bastante bien: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with-ls/
Quiere decir un número máximo de entradas en un solo directorio, ¿verdad?Después de todo, podría crear 2 millones de enlaces permanentes al mismo archivo en un directorio, y eso causaría el mismo problema. –