Hallo zusammen,
ich habe folgendes Problem: Mein (relativ großes) BTRFS Volume ist bei Schreiboperationen ziemlich fix unterwegs mit ~1GB/s aber sobald es ans Lesen geht, wird es ziemlich gruselig, was die Geschwindigkeit angeht. Hier lande ich üblicherweise bei <400MB/s. Das ist besonders interessant und erschreckend, da BTRFS eigentlich eher als "eher langsam bei Schreiboperationen wegen COW" bekannt ist, aber ich so gut wie keine Informationen zu besonders langsamer Lese-Performance im Netz finde.
Aber erstmal ein paar Daten zu dem Setup:
Es handelt sich um einen RAID 6 Setup bestehend aus 16 4TB WD-Blue HDDs, aufgespannt über einen Adaptec 71605 HW-Raid Controller. Ein einziges Set über alle 16 Platten. Nächster Layer ist ein LUKS Container mit einer Sector size von 4096, aufgespannt über das gesamte Set, was vom RAID Controller aufgespannt wurde. Und schlussendlich kommt dann die BTRFS Partition, die in dem LUKS Container erzeugt wurde (-d single -m dup).
Die CPU ist mit De-/Encryption nicht mal ansatzweise ausgelastet, hier werkelt ein i5-7600. RAM ist mit 16G auch ausreichend vorhanden, von dem gerade mal etwa 1G tatsächlich von Applikationen verwendet wird, der ganze Rest ist FS-Cache.
Auf diesem Setup hatte ich bis vor einiger Zeit statt einem BTRFS ein XFS volume, welches von der Read-Performance her *dramatisch* schneller war. Da sich allerdings auf diesem Set dann XFS nach langer Laufzeit entschieden hatte einfach mal sämtliche (Meta)Daten durch den Fleischwolf zu drehen, und eine Reperatur aufgrund von Tools, die gerne mal *extrem viel* RAM brauchen bei so einer Volumegröße, einfach nicht möglich war, bin ich auf das gemeinhin als robuster bekannte und gegen power-loss besser geschützte FS BTRFS geswitched. Allerdings häufen sich aktuell die Leseoperationen und die schlechte Lese-Performance schlägt hier ziemlich gravierend durch.
Das was mich an der Sache am meisten wundert, ist die hervorragende Schreib-Performance. Wenn ich einfach generell mit diesem FS lahm unterwegs wäre, könnte ich das Thema als (für meinen Anwendungszweck) unbrauchbar abhaken und mich nach Alternativen umschauen. Aber da es beim Schreiben mega fix ist und beim Lesen einbricht, gibt mir das schon echt zu Denken.
Habt ihr ähnliche Erfahrungen mit BTRFS gemacht? Hat jemand eine Idee oder kennt jemand eine Möglichkeit, wie man die Lese-Performance von BTRFS zumindest auf das Niveau der Schreib-Performance bekommt?
Wenn noch andere Eckdaten/Konfigurationen benötigt werden, kann ich die gerne zur Verfügung stellen.
[EDIT]: Mount options vom Volume sind "rw,relatime,space_cache,subvolid=5,subvol=/"
Kurzer Testlauf mit einer einzelnen 83GB (~85.293 MB) Datei über 10GBe/SMB - Gegenstelle ist eine Samsung 960 PRO 1TB NVMe SSD (3.5GB/s read | 2.1GB/s write):
Read: 6min56,5s (416,5s) ⇒ 204,78MB/s
Write: 1min34 (94s) ⇒ 907,37MB/s
Grüße Noc
Achso - Bevor die Fragen/Kommentare aufkommen, schonmal vorab 😉 :
Ja, mir ist klar, dass BTRFS im single-device mode nicht seine Stärken ausspielen kann und in diesem Setup SDC nicht (effektiv) verhindert wird.
ZFS habe ich ebenfalls getestet und ist in dem Setup keine Alternative. Ohne HW-Raid-Unterstützung ein zRaid aufspannen ist unterirdisch langsam und man bräuchte extrem viel RAM, um die Volume-Größe überhaupt sinnvoll mit ZFS betreiben zu können.
Software-Raid im allgemeinen ist in dem Setup keine Alternative, da die angestrebte Lese-/Schreibperformance ~1GB/s ist, und ich damit nicht die CPU quälen möchte. Die soll sich neben den Applikationen nur noch um De-/Encryption kümmern müssen.
Performance-Messungen direkt auf dem Set, direkt auf dem LUKS Container und mit anderen FS zeigen, dass es sich um ein Problem bei (der Konfiguration / dem Tuning von?) BTRFS handeln muss.
Ja, ich habe zusätzlich auch über 10GBe Datei-Transfers von *weit über 16GB* getestet, um Caching-Effekte vom FS-Cache für die gute Schreib-Performance ausschließen zu können und bekomme trotz (NW/SMB) overhead stabile ~1GB/s Schreibperformance hin auf dem Volume.