Schnellstes Linux-Dateisystem auf Shingled Disks

Es besteht ein erhebliches Interesse an Schindelantrieben. Dadurch werden Datenspuren so nahe beieinander platziert, dass Sie nicht auf eine Spur schreiben können, ohne die nächste zu überfrachten. Dies kann die Kapazität um etwa 20% erhöhen, führt jedoch zu Schreibverstärkungsproblemen. Derzeit wird an Dateisystemen gearbeitet, die für Shedled-Laufwerke optimiert sind. Siehe beispielsweise: https://lwn.net/Articles/591782/

Einige Shedled-Festplatten wie das Seagate 8-TB-Archiv verfügen über einen Cache-Bereich für zufällige Schreibvorgänge, der eine gute Leistung auf generischen Dateisystemen ermöglicht. Die Festplatte kann bei einigen gängigen Workloads sogar recht schnell sein, bis zu 200 MB / s Schreibvorgänge. Es ist jedoch zu erwarten, dass die Leistung beeinträchtigt werden kann, wenn der zufällige Schreibcache überläuft. Vermutlich können einige Dateisysteme zufällige Schreibvorgänge im Allgemeinen oder Muster zufälliger Schreibvorgänge, die den in solchen Laufwerken gefundenen Schreibcache möglicherweise überlaufen, besser vermeiden.

Kann ein Mainstream-Dateisystem im Linux-Kernel die Leistungseinbußen von Shedled-Festplatten besser vermeiden als ext4?

Intuitiv strukturierte Dateisysteme zum Kopieren beim Schreiben und Protokollieren bieten möglicherweise eine bessere Leistung auf Schindeldatenträgern, indem weniger zufällige Schreibvorgänge reduziert werden. Die Benchmarks unterstützen dies in gewisser Weise, diese Leistungsunterschiede sind jedoch nicht spezifisch für Schindelplatten. Sie treten auch auf einer nicht ausgeblendeten Festplatte auf, die als Steuerelement verwendet wird. Daher hat der Wechsel zu einer Schindelplatte möglicherweise keine große Relevanz für die Auswahl des Dateisystems.

Das nilfs2-Dateisystem lieferte auf der SMR-Festplatte eine recht gute Leistung. Dies lag jedoch daran, dass ich die gesamte 8-TB-Partition zugewiesen habe und der Benchmark nur ~ 0,5 TB schrieb, sodass der nilfs-Cleaner nicht ausgeführt werden musste. Als ich die Partition auf 200 GB beschränkte, wurden die Null-Benchmarks nicht einmal erfolgreich abgeschlossen. Nilfs2 ist in Bezug auf die Leistung möglicherweise eine gute Wahl, wenn Sie die "Archiv" -Diskette wirklich als Archivdiskette verwenden, auf der Sie alle Daten und Snapshots für immer auf die Diskette schreiben, da dann nilfs Cleaner nicht ausgeführt werden muss.

Ich verstehe, dass das 8-TB-Seagate- ST8000AS0002-1NA17ZLaufwerk, das ich für den Test verwendet habe, einen Cache-Bereich von ~ 20 GB hat. Ich habe die Standardeinstellungen für den Filebench-Dateiserver so geändert, dass die festgelegten Benchmarks ~ 125 GB betragen und größer als der nicht gespeicherte Cache-Bereich sind:

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

Nun zu den eigentlichen Daten. Die Anzahl der Operationen misst die "Gesamtleistung" des Dateiservers, während die ms / op die Latenz des zufälligen Anhängens misst und als grobe Richtlinie für die Leistung von zufälligen Schreibvorgängen verwendet werden kann.

$ 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]

Da das Seagate 5980 U / min hat, kann man naiv erwarten, dass das Toshiba 20% schneller ist. Diese Benchmarks zeigen, dass es ungefähr dreimal (200%) schneller ist, sodass diese Benchmarks den Leistungsverlust bei Schindeln erreichen. Wir sehen, dass Shingled (SMR) -Disketten immer noch nicht mit der Leistung von ext4 auf einer nicht gesungenen (PMR) -Diskette übereinstimmen können. Die beste Leistung wurde mit nilfs2 mit einer 8-TB-Partition erzielt (der Cleaner musste also nicht ausgeführt werden), aber selbst dann war er deutlich langsamer als der Toshiba mit ext4.

Um die oben genannten Benchmarks klarer zu machen, kann es hilfreich sein, sie im Verhältnis zur Leistung von ext4 auf jeder Festplatte zu normalisieren:

                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

Wir sehen, dass btrfs auf der SMR-Festplatte den größten Vorteil für die Gesamtoperationen hat, die es auf ext4 hat, aber die Strafe für zufällige Anhänge ist nicht so dramatisch wie ein Verhältnis. Dies kann dazu führen, dass man zu btrfs auf der SMR-Festplatte wechselt. Wenn Sie jedoch zufällige Anhänge mit geringer Latenz benötigen, schlägt dieser Benchmark vor, dass Sie xfs möchten, insbesondere für SMR. Wir sehen, dass SMR / PMR zwar die Wahl des Dateisystems beeinflussen kann, jedoch angesichts der Arbeitslast, für die Sie optimieren, wichtiger erscheint.

Ich habe auch einen Benchmark auf Dachbodenbasis durchgeführt. Die Dauer der Dachbodenläufe (auf den 8-TB-SMR-Partitionen mit voller Festplatte) betrug:

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

In jedem Fall hatten die Dachboden-Repositories die folgenden Statistiken:

                       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

Das Hinzufügen einer zweiten Kopie derselben 1-TB-Festplatte zum Dachboden dauerte auf jedem dieser drei Dateisysteme 4,5 Stunden. Eine Rohdatenbank der Benchmarks und smartctlInformationen finden Sie unter: http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR

Wenn Sie rsync von einem SMR-Laufwerk stammen, stellen Sie sicher, dass das Dateisystem bereitgestellt ist read-onlyoder über eine noatimeOption verfügt.

Andernfalls muss das SMR-Laufwerk für jeden rsync-Lesevorgang der Datei einen Zeitstempel schreiben, was zu einer erheblichen Leistungsverschlechterung (von etwa 80 MBit / s auf 3 bis 5 MBit / s hier) und zu Kopfverschleiß- / Klickgeräuschen führt.

Wenn Sie bereits einen Rsync-Job mit schlechter Leistung haben, müssen Sie ihn nicht stoppen. Sie können das Quelldateisystem erneut bereitstellen

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

Der Effekt wird nicht sofort sichtbar. Seien Sie geduldig und warten Sie 10 bis 20 Minuten, bis das Laufwerk alle noch in seinen Puffern befindlichen Daten ausgeschrieben hat. Dieser Rat hat sich bewährt.

Dies könnte auch gelten , wenn rsyncing zu einem SMR - Laufwerk, das heißt , wenn das Dateisystem den Zeitstempel zu aktualisieren versucht , nachdem die Datei auf der Festplatte vollständig geschrieben wurde. Dadurch wird die sequentielle Arbeitslast gestört, und riesige Datenbänder werden kontinuierlich neu geschrieben, was zum Verschleiß des Laufwerks beiträgt. Folgendes kann helfen:

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

Dies muss erfolgen, bevor rsync ausgeführt wird. Andere Faktoren können diese Option unbedeutend machen, z. B. ungepufferte FAT / MFT-Aktualisierung, parallelisierte Schreibvorgänge, wenn das Dateisystem hauptsächlich für SSDs optimiert ist usw.

Versuchen Sie, dd bs=32Mdas Dateisystem auf dem SMR-Ziel zu verwenden und seine Größe zu ändern, wenn Sie trotzdem vollständige Dateisysteme sichern möchten (in diesem Fall muss es nicht bereitgestellt und rsync ausgeführt werden, um jede einzelne Datei zu transportieren).

Die tatsächlich verwendete Hardware war ein von einem Seagate-Laufwerk verwaltetes SMR 8-TB-Consumer-Laufwerk. Ihr Kilometerstand kann mit anderer Hardware variieren.