Solución 1:
No use RAID0, una falla de cualquier unidad matará la matriz. RAID6, RAID10, incluso una sola unidad sin matriz sería mejor para la disponibilidad.
f2fs tiene la intención de ser compatible con los dispositivos de estado sólido modernos y Linux md puede funcionar muy rápido.
Sin embargo, imposible hacer declaraciones generales como f2fs en una matriz es mejor sin datos. Debe tener en cuenta cuál es su carga de trabajo, si el patrón de E/S se ha evaluado en un sistema similar al suyo y qué factores limitantes existen.
Haz un análisis de capacidad. Calcule cosas como consultas de base de datos por segundo o cuántos archivos se leen y escriben. Medir IOPS con herramientas como iostat -xz 1 . Si el r/s y w/s los números se acercan a la capacidad nominal del dispositivo, es posible que necesite discos más rápidos. Espere aproximadamente 100 IOPS por imán giratorio y al menos un par de miles de IOPS de la mayoría de los SSD. Y es diferente si los discos están conectados como SATA o NVMe.
Evaluar el rendimiento de cada recurso en el sistema. El almacenamiento rápido es de ayuda limitada si está limitado por la CPU o la memoria. La memoria es especialmente útil como caché. La paginación excesiva es mala, ya que el archivo de intercambio roba el rendimiento del sistema de almacenamiento pero no es tan rápido como la DRAM.
Una vez que comprenda el rendimiento del sistema ahora, puede comenzar a evaluar los cambios en el sistema de almacenamiento.
Solución 2:
Usar F2FS en un HDD clásico no es una buena idea:mientras que su rendimiento de escritura aleatoria probablemente sea mayor que EXT4 o XFS, la velocidad de lectura secuencial en un sistema de archivos antiguo será muy decepcionante.
Para aumentar el rendimiento de escritura aleatoria sin tener una caché de escritura no simultánea protegida contra pérdida de energía (léase:un verdadero controlador RAID), debe configurar sus aplicaciones para que no emita fsync(), pero esto lo hará aumentar significativamente las probabilidades de perder datos con un apagado no planificado. no deshabilite las barreras a nivel del sistema (es decir, diciéndole al kernel que ha escrito a través de cachés), ya que eso puede destruir todo el sistema de archivos en caso de pérdida de energía.
También puede considerar el uso de ZFS (preferiblemente dejando la creación de bandas para sí mismo, en lugar de la capa MDRAID):debido a su naturaleza CoW, las escrituras aleatorias son significativamente más rápidas que en otros sistemas de archivos, mientras que el almacenamiento en caché avanzado evita los problemas con las lecturas secuenciales. Incluso es compatible con sync=disabled :si puede tolerar una ventana de pérdida de datos de ~5 s en caso de un apagado inesperado, proporcionará una tonelada de IOP de escritura aleatoria sin afectar la consistencia de la aplicación o del sistema de archivos.
Finalmente, si está usando EXT4, puede hacer una prueba rápida con data=journal :si bien esto reducirá el rendimiento de la escritura secuencial, las escrituras aleatorias deberían ser un poco más rápidas que el modo diario predeterminado.