¿Linux File System garantiza un tiempo de acceso casi fijo a cualquier archivo en el disco duro?

Hablando prácticamente: no.

Incluso si ignoramos los detalles del sistema de archivos, debe lidiar con demoras de hardware (buscar la información del directorio, leerla, buscar dónde está el archivo, leerlo), almacenar en caché (en la unidad y en el núcleo), y otros procesos (el tiempo de E / S predecible es difícil si otro proceso repentinamente hace muchas E / S en el mismo disco).

Esperaría que el primer archivo sea más lento que el resto, solo porque arrastrará la mayoría de los metadatos de todo el directorio a la RAM en el proceso de averiguar en qué parte del disco reside físicamente el primer archivo. Dependiendo del sistema de archivos, el tamaño de los archivos, la fragmentación y la suerte, el sistema podría incluso leer de manera optimista los bloques que contienen el siguiente puñado de archivos en la memoria caché “mientras lo hace”, leer y almacenar en caché los datos justo después de lo que se le pide que lea. muy barato y a menudo acelera las cosas.

Dicho esto, en un sistema con poca carga, con los archivos en un SSD (que niega mucho el comportamiento de búsqueda y almacenamiento en caché del que hablo), y un sistema de archivos no estúpido, la respuesta se acercará mucho más a ser “sí” .

La respuesta se llama “HashTable”, y sí, ofrece un tiempo de acceso casi idéntico PARA CUALQUIER ARCHIVO, porque la siguiente operación es la misma para cualquier archivo dado:

  1. nombre de archivo dado -> calcular hashes
  2. usando hashes como clave en la matriz asociativa -> deriva el desplazamiento del archivo (es decir, la matriz asociativa almacena el par hash-> file_offset).

Estos conceptos se utilizan en BTRFS:

Btrfs

Y dentro del enlace de arriba se cita aquí:

una notable pérdida de rendimiento en otros sistemas de archivos con directorios ordenados por hash como ReiserFS, [68] ext3 (con índices Htree habilitados
[69]) y ext4, todos los cuales tienen nombres de archivo con TEA.

(Y así, ReiserFS, Ext3 / 4 están utilizando algún tipo de hash). Y de manera similar aquí:

Granada – Almacenamiento de miles y miles de millones de pequeños archivos pequeños – Alta escalabilidad –

Hay 2 partes importantes de su pregunta que merecen una inspección más cercana. El primero es que dices “Sistema de archivos Linux”. Bueno, no hay uno de esos … Hay muchos sistemas de archivos. Muchos funcionan en Linux, y en la mayoría de los casos también en otros sistemas operativos. ¿Quizás te refieres a la capa del sistema de archivos de Linux? Aun así, eso me lleva al segundo punto. Usaste la palabra “garantía”. Esto tiene un significado muy específico, y para ello debo decir “no” rotundamente y sin reservas.

Hay muchos factores que influyen en el acceso al disco. ¿Estás leyendo el archivo o escribiéndolo? ¿Es una unidad flash o un medio giratorio (puede haber un ciclo de borrado involucrado para flash, y los discos giratorios tienen varias advertencias)? La cantidad de archivos en el directorio es solo una parte, pero incluso eso difiere significativamente entre los sistemas de archivos. ¿Qué tan grande es el archivo? ¿Encaja en un solo inodo o abarca bloques directos e indirectos?

Básicamente, como se dijo, la respuesta es no.

Primero … ¿qué cuenta como el tiempo necesario para acceder a un archivo? ¿El tiempo transcurrido entre que se le dice a un programa que lea / escriba desde / a una ruta de archivo completa y qué tan rápido termina de leer / escribir? ¿O el tiempo que lleva enumerar los archivos para que pueda seleccionar uno? Si es posterior, casi no tiene influencia en ningún sistema de archivos, es el cuadro de diálogo / ventana que usa para mostrar la lista de archivos; si necesita mostrarlos todos, incluso si se desplaza fuera de la vista, llevará mucho tiempo incluso solo vea el contenido del directorio. Entonces, si te refieres a esto, FS no tiene nada que ver con eso; de lo contrario, sigue leyendo.

A continuación, con respecto a los archivos pequeños. Linux puede venir con varios sistemas de archivos. Incluso puede decidir cambiar el FS de un disco formateándolo nuevamente. El sistema de archivos más común es ext4, que es un buen todoterreno ya que no desperdicia mucha RAM, es razonablemente rápido con archivos grandes y muchos archivos pequeños, por ejemplo, XFS y ZFS no está muy contento con muchos archivos pequeños (especialmente no cuando los escribe / reescribe), ext4 los supera en más de 100000 archivos. Hay otros FS que están diseñados específicamente para ser lo más rápidos posible para escenarios específicos, por ejemplo, ReiserFS está diseñado para leer rápidamente desde muchos archivos pequeños, hasta el punto de que ni siquiera se nota entre 100 archivos y 100000000 (generalmente aproximadamente 10 veces más rápido que ext4). Sin embargo, no es muy rápido al escribir / reescribir / leer al azar de ellos (en cuyo caso es casi 100 veces más lento que ext4). Btrfs es un poco más lento en la lectura (digamos alrededor de 1,5 veces lo que hace Reiser), pero muchas veces más rápido en la escritura / reescritura y lectura aleatoria (alrededor de 10 veces más rápido que ext4). Probablemente hay muchos otros FS que tienen situaciones similares, aunque no los conozco todos, solo pueden referirse a los que realmente he usado.

Si realmente quieres lo más rápido para archivos tan pequeños, Btrfs tiene el mejor rendimiento general de los que he usado. Al menos desde mi propia experiencia. Y, de hecho, es similar a las pruebas de referencia realizadas aquí: ¿Cuál es el sistema de archivos Linux de más alto rendimiento para almacenar muchos archivos pequeños (HDD, no SSD)? Aunque tenga en cuenta que Btrfs es un “nuevo” sistema de archivos: no es tan maduro como algunos de los otros y aún puede tener algunos errores no encontrados, pero debería funcionar razonablemente bien en estos días (he escuchado muchas cosas buenas y muy malas) )

Sin embargo … ¿llevará tiempo constante? Probablemente no. Eso se debería a la técnica de indexación utilizada para nombrar e identificar archivos en el disco. Casi todos los FS utilizan un índice de árbol binario (o alguna derivada del mismo). Eso significa que el tiempo aún aumentaría, pero en cantidades cada vez más pequeñas. Por ejemplo, puede tomar 10 ms en 100 archivos, 19 ms en 1000, 25 ms en 10000, etc. Esto se conoce como algoritmo O (log N). El único algoritmo de complejidad de tiempo constante (O (1)) para dicha indexación es una tabla hash, que no se adapta muy bien a los sistemas de archivos, por lo que muy pocos de ellos la utilizan (al menos no solo para el conjunto completo de todos los directorios). – puede usarlo dentro de cada directorio individualmente, que es lo que creo que Btrfs y Reiser están haciendo).

Simplemente debe usar un SSD, unidad USB u otro almacenamiento flash que esté indexado. Eso asegurará que, independientemente del sistema de archivos MODERN que use, preferiblemente HFS + (registrado) para computadoras Apple, NTFS para computadoras Windows, ext4 para distribuciones de linux o exFAT para una máxima compatibilidad, aún debería tener velocidades bastante rápidas.