2009-03-05 13 views
6

Estoy en proceso de implementar el almacenamiento en caché para mi proyecto. Después de mirar las estructuras de directorio de caché, he visto muchos ejemplos como:Estructura del directorio de caché

cache 
cache/a 
cache/a/a/ 
cache/a/... 
cache/a/z 
cache/... 
cache/z 
... 

Ya entendió la idea. Otro ejemplo para el almacenamiento de archivos, digamos que nuestro archivo se llama IMG_PARTY.JPG, una forma común es ponerlo en un directorio llamado:

files/i/m/IMG_PARTY.JPG 

Algunos pensamientos vienen a la mente, pero me gustaría saber las verdaderas razones de esta.

  • sistemas de ficheros que hacen búsquedas lineales encontrar los archivos más rápido cuando hay menos de ellos en un directorio. Tal estructura propaga archivos delgados.

  • Para no estropear * nix utilidades como rm, que tienen un número finito de argumentos y eliminar gran número de archivos a la vez tiende a ser hacky (tener que pasar él sin embargo find etc.)

¿Cuál es el verdadero motivo? ¿Qué es una estructura de directorio de caché "buena" y por qué?

Respuesta

3

Cada vez que lo he hecho, ha sido para evitar búsquedas lineales lentas en sistemas de archivos. Afortunadamente, al menos en Linux, esto se está convirtiendo en una cosa del pasado.

Sin embargo, incluso hoy, con directorios basados ​​en b-tree, un directorio muy grande será difícil de tratar, ya que tomará una eternidad y un día solo para obtener una lista de todos los archivos, no importa encontrar el correcto archivo.

+0

Ah, pensé que tenía algo que ver con eso. Me encantaría saber qué FS todavía usan la búsqueda lineal. Esperaré por más respuestas antes de seleccionar una como aceptada, ¡gracias! – Karolis

+1

En Linux, ext2 y ext3 usan búsqueda lineal, a menos que la opción dir_index esté habilitada para el sistema de archivos (ha sido el predeterminado por un tiempo). En general, los viejos sistemas de archivos usan lineales, los nuevos usan árboles. –

2

Solo use fechas. Como eliminarás por fecha. :)

+0

Mi experiencia es que esto puede crear problemas de rendimiento, si alguna vez necesita borrar el caché manualmente, ya que todos los archivos creados inmediatamente después (precalentando el caché o cuando el público llega a algunas páginas populares) tendrán marcas de tiempo casi idénticas. –

2

Si hace ls -l, todos los archivos deben ser stat() ed para obtener detalles, lo que aumenta considerablemente el tiempo de listado: esto sucede si el FS usa estructuras hash o lineales.

Así que incluso si el FS tiene una capacidad de hacer frente a muy grandes tamaños de directorio, hay buenas razones para no cuentan con estructuras planas grandes (Son también un cerdo a una copia de seguridad)

He Benchmarked GFS2 (agrupado) con 32,000 archivos en un directorio u organizados en una estructura en árbol - los listados recursivos eran 300 veces más rápidos que obtener una lista cuando todos estaban en una estructura plana (podría tomar hasta 10 minutos obtener una lista de directorios)

EXT4 mostró proporciones similares, pero como el punto final fue solo un par de segundos, la mayoría de las personas no se daría cuenta.

Cuestiones relacionadas