Solution 1 :
N'utilisez pas RAID0, une défaillance de l'un des disques tuera la matrice. RAID6, RAID10, même un seul disque sans matrice serait préférable pour la disponibilité.
f2fs a l'intention d'être compatible avec les appareils à semi-conducteurs modernes, et Linux md peut aller très vite.
Cependant, impossible de faire des déclarations générales comme f2fs sur un tableau, c'est mieux sans données. Vous devez tenir compte de votre charge de travail, si le modèle d'E/S a été évalué sur un système similaire au vôtre et quels facteurs limitants existent.
Faites une analyse de capacité. Estimez des éléments tels que les requêtes de base de données par seconde ou le nombre de fichiers lus et écrits. Mesurez les IOPS avec des outils tels que iostat -xz 1 . Si le r/s et w/s approchent la capacité nominale de l'appareil, vous aurez peut-être besoin de disques plus rapides. Attendez-vous à environ 100 IOPS par rotation magnétique et au moins quelques milliers d'IOPS sur la plupart des SSD. Et cela change si les disques sont connectés en SATA ou NVMe.
Évaluez les performances de chaque ressource du système. Le stockage rapide est d'une aide limitée si vous êtes limité par le processeur ou la mémoire. La mémoire est particulièrement utile comme cache. Une pagination excessive est mauvaise, car le fichier d'échange vole les performances du système de stockage mais n'est pas aussi rapide que la DRAM.
Une fois que vous comprenez maintenant les performances du système, vous pouvez commencer à évaluer les modifications apportées au système de stockage.
Solution 2 :
Utiliser F2FS sur un disque dur classique n'est pas une bonne idée :alors que ses performances en écriture aléatoire seront probablement supérieures à EXT4 ou XFS, la vitesse de lecture séquentielle sur un système de fichiers vieillissant sera très décevante.
Pour augmenter les performances d'écriture aléatoire sans disposer d'un cache en écriture protégé contre les pertes de puissance (lire :un véritable contrôleur RAID), vous devez configurer vos applications pour ne pas lancer fsync(), mais cela va augmentent considérablement les risques de perte de données en cas d'arrêt imprévu. Ne pas désactivez les barrières au niveau du système (c'est-à-dire en indiquant au noyau que vous avez écrit dans les caches), car cela peut détruire tout le système de fichiers en cas de perte de puissance.
Vous pouvez également envisager d'utiliser ZFS (en laissant de préférence le striping à lui-même, plutôt qu'à la couche MDRAID) :en raison de sa nature CoW, les écritures aléatoires sont nettement plus rapides que sur d'autres systèmes de fichiers, tandis que la mise en cache avancée évite les problèmes de lectures séquentielles. Il prend même en charge sync=disabled :si vous pouvez tolérer une fenêtre de perte de données d'environ 5 s en cas d'arrêt inattendu, cela fournira une tonne d'IOP d'écriture aléatoire sans affecter la cohérence de l'application ou du système de fichiers.
Enfin, si vous utilisez EXT4, vous pouvez faire un test rapide avec data=journal :bien que cela réduise les performances d'écriture séquentielle, les écritures aléatoires devraient être un peu plus rapides que le mode de journal par défaut.