Digamos que comienza con una pizarra en blanco, es decir, no ha accedido al sistema de archivos en absoluto. Ahora digamos que ejecuta stat ("/ some / dir / file"). Primero, el núcleo tiene que encontrar el archivo, que en términos técnicos se llama inodo. Comienza buscando en el superbloque del sistema de archivos, que almacena el inodo del directorio raíz. Luego abre el directorio raíz, encuentra "algunos", abre eso, encuentra "dir", etc., finalmente encuentra el inodo para el archivo.
Entonces tienes que leer los datos del inodo. Después de la primera lectura, esto también se almacena en caché en la RAM. Entonces, una lectura solo tiene que suceder una vez.
Piense en la HD como un viejo tocadiscos, una vez que esté en el lugar correcto con la aguja, puede seguir leyendo rápidamente mientras gira. Sin embargo, una vez que necesita mudarse a un lugar diferente, llamado "buscar", está haciendo algo muy diferente. Debe mover físicamente el brazo, luego esperar a que el plato gire hasta que el lugar correcto esté debajo de la aguja. Este tipo de movimiento físico es inherentemente lento, por lo que los tiempos de búsqueda de discos son bastante largos.
Entonces, ¿cuándo buscamos? Depende del diseño del sistema de archivos, por supuesto. Los sistemas de archivos intentan almacenar archivos consecutivamente para aumentar el rendimiento de lectura, y generalmente también intentan almacenar inodos para un solo directorio cerca uno del otro, pero todo depende de cosas como cuándo se escriben los archivos, fragmentación del sistema de archivos, etc. caso, cada estadística de un archivo provocará una búsqueda y luego cada apertura del archivo provocará una segunda búsqueda. Entonces, es por eso que las cosas tardan tanto tiempo cuando nada se almacena en caché.
Algunos sistemas de archivos son mejores que otros, la desfragmentación puede ayudar. Puedes hacer algunas cosas en las aplicaciones. Por ejemplo, GIO ordena los inodos recibidos de readdir () antes de declararlos esperando que el número de inodo tenga algún tipo de relación con el orden del disco (generalmente lo tiene), minimizando así las búsquedas aleatorias de un lado a otro.
Una cosa importante es diseñar su almacenamiento de datos y aplicaciones para minimizar la búsqueda. Por ejemplo, esta es la razón por la cual la lectura / usr / bin de Nautilus es lenta, porque los archivos allí generalmente no tienen extensión, necesitamos hacer un sniffing mágico para cada uno. Entonces, necesitamos abrir cada archivo => una búsqueda por archivo => slooooow. Otro ejemplo son las aplicaciones que almacenan información en muchos archivos pequeños, como solía hacer gconf, también una mala idea. De todos modos, en la práctica no creo que haya mucho que puedas hacer, excepto tratar de ocultar las latencias.