Système de fichiers Linux le plus rapide sur les disques bardés

Les lecteurs de bardeaux présentent un intérêt considérable. Ceux-ci placent les pistes de données si près les unes des autres que vous ne pouvez pas écrire sur une piste sans enchaîner la suivante. Cela peut augmenter la capacité d'environ 20%, mais entraîne des problèmes d'amplification d'écriture. Des travaux sont en cours sur les systèmes de fichiers optimisés pour les lecteurs Shingled, par exemple, voir: https://lwn.net/Articles/591782/

Certains disques bardés tels que l'archive Seagate 8 To ont une zone de cache pour les écritures aléatoires, permettant des performances décentes sur les systèmes de fichiers génériques. Le disque peut même être assez rapide sur certaines charges de travail courantes, jusqu'à des écritures de 200 Mo / s. Cependant, il est à prévoir que si le cache d'écriture aléatoire déborde, les performances peuvent en souffrir. Vraisemblablement, certains systèmes de fichiers sont plus efficaces pour éviter les écritures aléatoires en général, ou les modèles d'écritures aléatoires susceptibles de déborder le cache d'écriture trouvé dans de tels lecteurs.

Un système de fichiers traditionnel dans le noyau Linux est-il meilleur pour éviter la pénalité de performance des disques bardés que ext4?

Les systèmes de fichiers structurés à copie et écriture intuitifs peuvent donner de meilleures performances sur les disques bardés en réduisant les écritures aléatoires. Les benchmarks le supportent quelque peu, cependant, ces différences de performances ne sont pas spécifiques aux disques bardés. Ils se produisent également sur un disque non chiffré utilisé comme contrôle. Ainsi, le passage à un disque bardé peut ne pas avoir beaucoup de pertinence pour votre choix de système de fichiers.

Le système de fichiers nilfs2 a donné de très bonnes performances sur le disque SMR. Cependant, cela était dû au fait que j'avais alloué la partition entière de 8 To et que le test de référence n'écrivait que ~ 0,5 To afin que le nettoyeur nilfs n'ait pas à s'exécuter. Lorsque j'ai limité la partition à 200 Go, les tests de performances nilfs ne se sont même pas terminés avec succès. Nilfs2 peut être un bon choix en termes de performances si vous utilisez vraiment le disque "archive" comme un disque d'archive où vous conservez pour toujours toutes les données et les instantanés écrits sur le disque, car alors nilfs cleaner n'a pas à s'exécuter.

Je comprends que le ST8000AS0002-1NA17Zlecteur Seagate de 8 To que j'ai utilisé pour le test a une zone de cache de ~ 20 Go . J'ai modifié les paramètres par défaut du serveur de fichiers filebench afin que l'ensemble de références soit ~ 125 Go, plus grand que la zone de cache débridée:

set $meanfilesize=1310720
set $nfiles=100000
run 36000

Maintenant, pour les données réelles. Le nombre d'opérations mesure les performances "globales" du serveur de fichiers tandis que le ms / op mesure la latence de l'ajout aléatoire, et pourrait être utilisé comme un guide approximatif des performances des écritures aléatoires.

$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' |  column -t
SMR8TB.nilfs   appendfilerand1   292176ops 8ops/s   0.1mb/s   1575.7ms/op    95884us/op-cpu [0ms - 7169ms]
SMR.btrfs      appendfilerand1  214418ops  6ops/s   0.0mb/s  1780.7ms/op  47361us/op-cpu  [0ms-20242ms]
SMR.ext4       appendfilerand1  172668ops  5ops/s   0.0mb/s  1328.6ms/op  25836us/op-cpu  [0ms-31373ms]
SMR.xfs        appendfilerand1  149254ops  4ops/s   0.0mb/s  669.9ms/op   19367us/op-cpu  [0ms-19994ms]
Toshiba.btrfs  appendfilerand1  634755ops  18ops/s  0.1mb/s  652.5ms/op   62758us/op-cpu  [0ms-5219ms]
Toshiba.ext4   appendfilerand1  466044ops  13ops/s  0.1mb/s  270.6ms/op   23689us/op-cpu  [0ms-4239ms]
Toshiba.xfs    appendfilerand1  368670ops  10ops/s  0.1mb/s  195.6ms/op   19084us/op-cpu  [0ms-2994ms]

Comme le Seagate est à 5980 tr / min, on pourrait naïvement s'attendre à ce que le Toshiba soit 20% plus rapide. Ces benchmarks montrent qu'il est environ 3 fois (200%) plus rapide, donc ces benchmarks frappent la pénalité de performance en bardeaux. Nous voyons que le disque Shingled (SMR) ne peut toujours pas correspondre aux performances ext4 avec un disque non chiffré (PMR). La meilleure performance était avec nilfs2 avec une partition de 8 To (donc le nettoyeur n'avait pas besoin de fonctionner), mais même alors, c'était beaucoup plus lent que le Toshiba avec ext4.

Pour rendre les repères ci-dessus plus clairs, il pourrait être utile de les normaliser par rapport aux performances d'ext4 sur chaque disque:

                ops     randappend
SMR.btrfs:      1.24    0.74
SMR.ext4:       1       1
SMR.xfs:        0.86    1.98
Toshiba.btrfs:  1.36    0.41
Toshiba.ext4:   1       1
Toshiba.xfs:    0.79    1.38

Nous voyons que sur le disque SMR, btrfs a la plupart des avantages sur les opérations globales qu'il a sur ext4, mais la pénalité sur les ajouts aléatoires n'est pas aussi dramatique qu'un ratio. Cela pourrait conduire à passer à btrfs sur le disque SMR. D'un autre côté, si vous avez besoin d'ajouts aléatoires à faible latence, ce benchmark suggère que vous souhaitiez xfs, en particulier sur SMR. Nous voyons que bien que SMR / PMR puisse influencer votre choix de système de fichiers, la charge de travail que vous optimisez semble plus importante.

J'ai également dirigé un benchmark basé sur le grenier. Les durées des passages du grenier (sur les partitions de disque complet SMR de 8 To) étaient les suivantes:

ext4:  1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds

Dans chaque cas, les dépôts du grenier avaient les statistiques suivantes:

                       Original size      Compressed size    Deduplicated size
This archive:                1.00 TB            639.69 GB            515.84 GB
All archives:              901.92 GB            639.69 GB            515.84 GB

L'ajout d'une deuxième copie du même disque de 1 To au grenier a pris 4,5 heures sur chacun de ces trois systèmes de fichiers. Un vidage brut des benchmarks et des smartctlinformations se trouve sur: http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR

Si vous à rsync partir d' un lecteur SMR, assurez-vous que le système de fichiers est monté read-onlyou avec noatimeoption.

Sinon, le lecteur SMR devra écrire un horodatage pour chaque fichier rsync lu, ce qui entraînera une dégradation significative des performances (d'environ 80 Mo / s à 3-5 Mo / s ici) et une usure de la tête / un bruit de clic.

Si vous avez déjà un travail rsync en cours d'exécution avec de mauvaises performances, il n'est pas nécessaire de l'arrêter, vous pouvez remonter le système de fichiers source en faisant

sudo mount -o remount,ro  /path/to/source/fs

L'effet ne sera pas visible immédiatement, soyez patient et attendez 10 à 20 minutes, jusqu'à ce que le lecteur ait fini d'écrire toutes les données encore dans ses tampons. Ce conseil a fait ses preuves.

Cela peut également s'appliquer lorsque vous rsynctravaillez sur un lecteur SMR, c'est-à-dire si le système de fichiers essaie de mettre à jour l'horodatage une fois le fichier entièrement écrit sur le disque. Cette charge de travail séquentielle instable et d'énormes bandes de données sont continuellement réécrites, ce qui contribue à l'usure du lecteur. Les éléments suivants peuvent être utiles:

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

Cela doit être fait avant l'exécution de rsync; d'autres facteurs peuvent rendre cette option insignifiante, à savoir la mise à jour FAT / MFT sans tampon, les écritures parallélisées si le système de fichiers est principalement optimisé pour les SSD, etc.

Essayez d'utiliser dd bs=32Mpuis de redimensionner le système de fichiers sur la cible SMR, si vous voulez quand même sauvegarder des systèmes de fichiers complets (pas besoin de le monter et d'exécuter rsync pour transporter chaque fichier dans ce cas).

Le matériel réellement utilisé était un disque grand public SMR 8 To géré par Seagate. Votre kilométrage peut varier avec d'autres matériels.