¿Cuál es el sistema de archivos Linux de más alto rendimiento para almacenar una gran cantidad de archivos pequeños (HDD, no SSD)?

43

Tengo un árbol de directorios que contiene muchos archivos pequeños y una pequeña cantidad de archivos más grandes. El tamaño promedio de un archivo es de aproximadamente 1 kilobyte. Hay 210158 archivos y directorios en el árbol (este número se obtuvo al ejecutar find | wc -l).

Un pequeño porcentaje de archivos se agrega / elimina / reescribe varias veces por semana. Esto se aplica a los archivos pequeños, así como a (un pequeño número de) archivos más grandes.

Los sistemas de archivos que probé (ext4, btrfs) tienen algunos problemas con el posicionamiento de los archivos en el disco. Durante un período de tiempo más largo, las posiciones físicas de los archivos en el disco (medios rotativos, no discos de estado sólido) se están distribuyendo de manera más aleatoria. La consecuencia negativa de esta distribución aleatoria es que el sistema de archivos se está volviendo más lento (por ejemplo: 4 veces más lento que un sistema de archivos nuevo).

¿Existe un sistema de archivos de Linux (o un método de mantenimiento del sistema de archivos) que no sufra esta degradación del rendimiento y pueda mantener un perfil de rendimiento estable en un medio rotativo? El sistema de archivos puede ejecutarse en Fuse, pero debe ser confiable.

linux filesystems performance
fuente
Si sabe qué archivos serán grandes / no cambiarán muy a menudo, y cuáles serán pequeños / cambiarán con frecuencia, es posible que desee crear dos sistemas de archivos con diferentes opciones, más adecuados para cada escenario. Si necesita que sean accesibles ya que formaban parte de la misma estructura, puede hacer algunos trucos con mount, symlinks.
Marcin
Me sorprende mucho saber que btrfs (con la función de copiar y escribir) ha sido lento para usted durante un período de tiempo. Tengo curiosidad por compartir los resultados de usted, posiblemente ayudándose mutuamente en una nueva dirección de ajuste de rendimiento.
Nikhil Mulley
hay un nuevo animal en línea zfs en Linux, disponible en modo nativo e implementaciones de fusibles, en caso de que desee echar un vistazo.
Nikhil Mulley
Intenté zfs en Linux una vez, era bastante inestable. Gestionado para bloquear completamente el sistema de archivos con bastante frecuencia. Box funcionaría, pero cualquier acceso al FS quedaría bloqueado.
Patrick
Similar post serverfault.com/questions/6711/…
Nikhil Mulley

Respuestas:

47

Actuación

Escribí un pequeño Benchmark ( fuente ), para averiguar qué sistema de archivos funciona mejor con cientos de miles de archivos pequeños:

  • crear 300000 archivos (512B a 1536B) con datos de / dev / urandom
  • reescribe 30000 archivos aleatorios y cambia el tamaño
  • leer 30000 archivos secuenciales
  • leer 30000 archivos aleatorios

  • Borrar todos los archivos

  • sincronizar y soltar caché después de cada paso

Resultados (tiempo promedio en segundos, menor = mejor):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Resultado: si
bien Ext4 tuvo un buen rendimiento general, ReiserFS fue extremadamente rápido en la lectura de archivos secuenciales. Resultó que XFS es lento con muchos archivos pequeños; no debe usarlo para este caso de uso.

Problema de fragmentación

La única forma de evitar que los sistemas de archivos distribuyan archivos a través del disco es mantener la partición tan grande como realmente la necesite, pero preste atención para no hacer que la partición sea demasiado pequeña, para evitar la fragmentación de archivos internos. Usar LVM puede ser muy útil.

Otras lecturas

Arch Wiki tiene excelentes artículos relacionados con el rendimiento del sistema de archivos:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

taffer
fuente
44
Debe especificar en qué versión del núcleo está basando esa comparación. XFS obtuvo algunas mejoras de velocidad muy significativas en uno de los núcleos recientes (creo que fue 2.6.31, pero no me cite al respecto).
Patrick
1
btrfs internamente hace tu truco lvm. Asigna trozos más pequeños del disco y coloca archivos en esos trozos, luego solo asigna otro trozo del disco cuando se llenan los trozos existentes.
psusi
1
Eso es cierto para cualquier sistema de archivos. Es por eso que las aplicaciones usan cosas como fsync ().
psusi
2
@taffer, lo es. Las transacciones tienen el mismo efecto que el diario en otros sistemas de archivos: protegen los metadatos fs. En teoría, pueden ser utilizados por las aplicaciones de la manera que usted describe, pero actualmente no hay una API para permitir que las aplicaciones abran y cierren transacciones.
psusi
1
@taffer Su "punto de referencia reciente" es de abril de 2015, tiene más de tres años y usa XFS con solo opciones predeterminadas. Esto es anterior a xfsprogs 3.2.3 que hace que XFS v5 sea el predeterminado y todos los beneficios que trae. Tampoco fue formateado con -m finobt = 1, que es un cambio de juego para el rendimiento de XFS con archivos pequeños y actualizaciones de metadatos pesados. No, no hay viñetas plateadas, pero basar su opinión en puntos de referencia antiguos no es aconsejable, especialmente cuando se ignoraron, no estuvieron disponibles o se deshabilitaron las principales características de cambio de rendimiento.
Jody Lee Bruchon el
7

Estoy usando ReiserFS para esta tarea, está especialmente diseñado para manejar muchos archivos pequeños. Hay un texto fácil de leer al respecto en el wiki de funtoo.

ReiserFS también tiene una serie de características destinadas específicamente a mejorar el rendimiento de archivos pequeños. A diferencia de ext2, ReiserFS no asigna espacio de almacenamiento en bloques fijos de una o cuatro k. En cambio, puede asignar el tamaño exacto que necesita.

Baarn
fuente
1
También hay problemas de estabilidad con ReiserFS, por lo que RH y SuSE han eliminado ese FS. Desde el principio (BTree-based-FS) BTRFS debería ser comparable.
Nils
0

XFS se destaca por desempeñarse muy bien en situaciones como esta. Esto es parte de por qué lo usamos en mi trabajo para nuestros almacenes de correo (que pueden contener cientos de miles de archivos en 1 directorio). Tiene mejor tolerancia a fallas que ReiserFS, se usa mucho más y generalmente es un sistema de archivos muy maduro.

Además, XFS admite la desfragmentación en línea. Aunque utiliza una técnica de asignación retrasada que resulta en una menor fragmentación (en comparación con otros sistemas de archivos) para empezar.

Patricio
fuente
20
XFS se destaca por su excelente desempeño en situaciones como esta. [cita requerida]
taffer
8
Ehm, xfs es especialmente conocido por lo contrario: funciona muy bien con archivos grandes, ¡pero no tan bien con archivos pequeños! Mire este exhaustivo punto de referencia, por ejemplo (o vaya directamente a la conclusión en la página 10 ^^): ilsistemista.net/index.php/linux-a-unix/…
Levite el
1
@Levit Creo que estás leyendo mal ese informe. El informe muestra muy claramente que XFS funciona muy bien para E / S aleatorias. Pero aparte de eso, el informe no aborda el tipo de escenario en esta pregunta, muchos archivos. IO aleatorio es una cosa, un gran número de archivos es donde ext * cae en su cara.
Patrick
2
El único lugar en el que XFS es realmente mejor es en las operaciones de lectura / escritura aleatorias (aún parece extraño que un patrón de lectura verdaderamente aleatorio en un disco mecánico pueda obtener 10 MB / s, me parece una optimización que no vuela en el mundo real (en mi humilde opinión)), mientras que en la página 7 muestra lo que dije anteriormente, ¡XFS es realmente bueno para manejar archivos grandes! ¡Mire las páginas 3 y 5, especialmente en la 3, verá que maneja archivos pequeños claramente no tan bien como ext! Sin embargo, realmente no tengo nada en contra de XFS, pero por lo que encuentras en todas partes, no es la mejor opción para muchos archivos pequeños, ¡es todo lo que digo!
Levite
55
XFS también puede ser extremadamente lento cuando se trata de archivos grandes, si estos archivos se extienden de forma aleatoria / lenta con pequeños fragmentos durante mucho tiempo. (El syslogdpatrón típico ). Por ejemplo, a mi lado en una configuración XFS sobre MD acabo de observar que eliminar un archivo de 1,5 GB tardó 4,75 minutos (!) Mientras la unidad de disco se limitó a un límite de 100 transacciones / s a ​​una velocidad de escritura de más de 2 MB / s. Esto también afecta el rendimiento de otras operaciones de E / S paralelas en el mismo disco, ya que el disco ya está al máximo. Nunca vi algo así en otros FS (o ser probado en puntos de referencia).
Tino