Totalausfall ZFS

Apr 13, 2016
16
0
6
Hallo,
folgende Hardware: HPE DL380 Gen10, 6 * 8TB HDD, 2 * 500MB SSD für Daten, zusätzlich 2* 240MB SSD fürs Betriebssystem, 512 GB RAM, 2* CPU Xeon Gold <irgendwas>
Der Server kann die Datenplatten entweder als HW-RAID ansprechen oder als HBA ansprechen. Ich wollte ZFS einsetzen.

Meine Tests sind weit fortgeschritten, ich erhiellt keine einzige brauchbare Konfiguration. Alles Müll....

Egal ob ich einen ZFS Verbund der 6 HDD als RAID-Z1, RAID-Z2 oder RAID-10 aufsetzte, egal ob ich die SSD als L2ARC oder fürs Journal einsetzte oder nicht, egal ob ich sync=Standard oder sync=always nutze, erhielt ich folgende Symptomatik: Schreibvorgänge sind unerträglich langsam.

Es sollten z.B. während der Versuche vzdump-Dateien aus dem Produktivsystem auf die neuen Server per NFS übertragen werden. Alter und neuer Server sind mit 10 GB/s miteinander verbunden, der alte Server kann die vzdump-Dateien mit ca 300 MB/s von seiner Platte lesen, und mit diesen Werten kommen sie auch beim neuen Server an. Hat der alte Server diese bereits in seinem Cache, so kommen die Daten mit mehr als 1 GB/s an. OK soweit für den LAN-Anteil.

Dann beginnt das Trauerspiel: Mache ich auf dem neuen Server ein Restore, so werden zuerst die Prozentzahlen relativ schnell hochgezählt, aber nach einigen Prozentpunkten verlangsamt sich der Restoreprozeß bis zur völligen Untauglichkeit. Lagen (fiktive Werte, aber es lag in diesen Bereichen) zwischen 1% und vielleicht 7% Zeitabstände von 60 Sekunden zwischen den Prozentpunkten, so verlangsamt sich das danach auf Werte von bis zu Stunden zwischen den einzelnen Prozentpunkten. Wir reden hierbei vom Restore einer VM mit etwas weniger als 1 TB an Platten und einer vzdump-Datei von ca 400 GB. Bei kleineren VM kommt der beschriebene Effekt eben etwas später, aber er kommt. Teilweise werden 100% erreicht, aber dann folgt eine Gedenkstunde bis "Task OK" erscheint.

Was ich herausfand: Mittels "cat /proc/meminfo" sah ich, daß der "Dirty"-Wert abstrus hohe Werte annimmt. Während die Prozentzahlen noch schnell ansteigen, steigt der "Dirty"-Wert ebenfalls und kann durchaus Werte von 90 GB erreichen. Er sinkt -auch wenn keine Schreibzugriife mehr erfolgen- nur extrem langsam wieder ab. Es dauert somit wiederum Stunden, bis der Linux-Schreibcache auf die Platten gekommen ist. Ein "sync" verharrt dann ebenfalls diese Zeit.

iostat wirft Werte von in der Regel 8000 kB/s für die Schreibvorgänge auf die einzelnen Platten des ZFS-Verbunds aus, was natürlich unterirdisch schlecht ist. Gleichzeitig liegt die Utilization der Platten bei für diese mickrige Schreibrate bei Werten von ca 80-90%.

Eine Möglichkeit, eine Festplatte so dermaßen langsam zu bekommen, wäre die wahllose Verteilung der Daten auf die Platte mit unzähligen Kopfbewegungen. Ich wage zu hoffen, daß ZFS das nicht in dieser Form macht. Eine weitere Möglichkeit wäre, sich tot zu administrieren. Die CPU-Auslastungen sind aber relativ gering.

Nutze ich die Platten als HW-RAID, dann erhalte ich "vernünftige" und der Hardware entsprechende Werte: Die beschriebene VM ist in weniger als 1 Stunde auf dem neuen Server lauffähig, der Dirty-Wert erreicht während des Restore kaum mal 1 GB (meist sehr viel weniger, und er sinkt auch sehr schnell wieder ab), die Schreibrate auf das Array -wiederum mit iostat ermittelt- liegt bei 6-stelligen Werten, oftmals hat das HW-RAID sogar Zeit für Pausen, und Writeback-SSD ist da noch nicht einmal im Spiel.

Was mir noch auffiel: Bei den ZFS-Versuchen erhielt ich 7-stellige Prozeß-ID, obwohl der Server erst seit ein paar Tagen lief und noch nichts Produktives geleistet hatte. Beim Versuch mit HW-RAID blieben die Prozeß-ID im üblichen 5-stelligen Bereich. Das könnte (wilde Spekulation) darauf hindeuten, daß ZFS für jeden mickrigen Schreibvorgang einen eigenen Prozeß mit erheblichem Overhead erzeugt.

Verbleibt noch zu erwähnen, daß ich nach wie vor ZFS u.A. aufgrund der Replikationsmöglichkeiten einsetzen will.
 
Apr 13, 2016
16
0
6
512 GB... sollte ja wohl reichen. Es läuft bis auf das Restore nichts auf den Kisten

Nachtrag: Ich vergaß, die Proxmox-Version zu erwähnen. Also: 6.0-7, aktuellste Ware aus dem subscription-Repository.

Ein gestern gestartetes Restore:
restore vma archive: lzop -d -c /mnt/pve/nfs/dump/vzdump-qemu-113-2019_10_13-01_12_37.vma.lzo | vma extract -v -r /var/tmp/vzdumptmp1405330.fifo - /var/tmp/vzdumptmp1405330
CFG: size: 477 name: qemu-server.conf
DEV: dev_id=1 size: 429496729600 devname: drive-virtio0
DEV: dev_id=2 size: 644245094400 devname: drive-virtio1
DEV: dev_id=3 size: 301721452544 devname: drive-virtio2
CTIME: Sun Oct 13 01:12:38 2019
new volume ID is 'zfs:vm-102-disk-0'
map 'drive-virtio0' to '/dev/zvol/zfs/vm-102-disk-0' (write zeros = 0)
new volume ID is 'zfs:vm-102-disk-1'
map 'drive-virtio1' to '/dev/zvol/zfs/vm-102-disk-1' (write zeros = 0)
new volume ID is 'zfs:vm-102-disk-2'
map 'drive-virtio2' to '/dev/zvol/zfs/vm-102-disk-2' (write zeros = 0)
progress 1% (read 13754695680 bytes, duration 39 sec)
progress 2% (read 27509325824 bytes, duration 75 sec)
progress 3% (read 41263955968 bytes, duration 109 sec)
[...]
progress 7% (read 96282476544 bytes, duration 735 sec)
progress 8% (read 110037106688 bytes, duration 4177 sec)
progress 9% (read 123791736832 bytes, duration 7217 sec)
progress 10% (read 137546366976 bytes, duration 9985 sec)

[...]
progress 11% (read 151300997120 bytes, duration 12974 sec)
progress 12% (read 165055627264 bytes, duration 15730 sec)
progress 13% (read 178810257408 bytes, duration 18191 sec)
[...]
progress 34% (read 467657555968 bytes, duration 68090 sec)

Letztes ist der aktuelle Stand. Völlig unbrauchbar, Oben sieht man die Prozeß-ID des Restore (1405330). Inzwischen ist der Rechner bei ca 4400000. Da werden also Millionen an nur kurz laufenden Prozessen erzeugt.
 

franz78

New Member
Oct 11, 2018
14
0
1
41
kannst du uns bitte mal ein "zpool status" posten.
Welche SSD's verwendest du?
Hast du schon testweise "sync=disabled" probiert?
Was zeigt pveperf /<deinpool> an ?

Die Ausgabe von
hdparm -W /dev/<disk>
 
Apr 13, 2016
16
0
6
Code:
root@pve13:~# zpool status
  pool: zfs
 state: ONLINE
  scan: scrub repaired 0B in 0 days 00:06:17 with 0 errors on Sun Oct 13 00:30:18 2019
config:

        NAME        STATE     READ WRITE CKSUM
        zfs         ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0
            sdg     ONLINE       0     0     0
            sdh     ONLINE       0     0     0
im aktuellen Verbund sind gar keine SSD verwendet, aber es sind HPE "Mixed Used SSD", keine Consumerhardware.

Code:
root@pve13:~# pveperf /zfs
CPU BOGOMIPS:      192030.08
REGEX/SECOND:      3963295
HD SIZE:           28843.13 GB (zfs)
FSYNCS/SECOND:     1076.63
DNS EXT:           70.83 ms
DNS INT:           1.25 ms (xxxxx.xxxxx.de)
Code:
root@pve13:~# hdparm -W /dev/sdc

/dev/sdc:
SG_IO: bad/missing sense data, sb[]:  72 05 20 00 00 00 00 10 02 06 00 00 c0 00 00 00 03 02 00 21 80 02 f8 21 00 00 00 00 00 00 00 00
 write-caching = not supported
Die Fehlermeldung erhalte ich bei jeder Platte (außer den SSD).

bei sync=disabled steigt zwar nicht "Dirty" in /proc/meminfo an, sondern Writeback. Ansonsten ist das Verhalten ebenso übel.
 

franz78

New Member
Oct 11, 2018
14
0
1
41
hast du die Möglichkeit als Test nur die SSD's zu verwenden. Also einen ZFS spiegel und danach spielst du das Backup zurück.
 
Apr 13, 2016
16
0
6
klar.. hab ja inzwischen Routine :)

Das erfreut das Herz: Die Backup-Datei war in diesem Fall ca 60 GB groß.
Code:
progress 99% (read 106300440576 bytes, duration 306 sec)
progress 100% (read 107374182400 bytes, duration 309 sec)
total bytes read 107374182400, sparse bytes 12165922816 (11.3%)
space reduction due to 4K zero blocks 0.61%
rescan volumes...
TASK OK
Zwischenzeitlich habe ich noch anderes probiert. Obwohl man es nicht tun soll, habe ich alle HDD als separate LogicalDrives des RAID-Controllers eingerichtet. Das Ergebnis war ebenso schlecht wie im HBA-Modus. Schalte ich aber den Schreibcache des Controllers ein, dann erhalte ich ganz andere Ergebnisse. Richtig brauchbar...

Ein halb so großes Backup (30 GB) - erreicht wurden 6-stellige Anzeigewerte für das Schreiben. Zwar füllte sich der Writeback-Wert und es dauerte einige zig-Sekunden zwischen "100%" und "Task OK", aber das System ist so wenigstens brauchbar:
Code:
progress 98% (read 84181385216 bytes, duration 203 sec)
progress 99% (read 85040365568 bytes, duration 203 sec)
progress 100% (read 85899345920 bytes, duration 203 sec)
total bytes read 85899345920, sparse bytes 10702393344 (12.5%)
space reduction due to 4K zero blocks 0.498%
rescan volumes...
TASK OK
Es setzt sich bei mir der Verdacht fest, daß ZFS die Schreibzugriffe "wild" auf den Platten verteilt und die Kopfbewegungszeiten jede Performance unmöglich machen.
 

LnxBil

Famous Member
Feb 21, 2015
4,327
428
103
Germany
Hast du einen "richtigen, dummen" HBA den du mal alternativ verwenden kannst? Ich habe was im Hinterkopf, dass es mit den P-<irgendwas> Standard-Controllern unter HPE zu Performanceproblemen kommen kann. Ich hab unsere Platte auch über einen "dummen HBA" dranhängen und nicht über den Standard HBA.
 
Apr 13, 2016
16
0
6
Ich habe im Keller noch einen IBM ServeRAID gefunden, eigentlich ein LSI SAS9220-8i, der aber noch zum HBA umgeflasht werden müßte. Kennt jemand eine gute und verläßliche Anleitung zu diesem Tun?
Außerdem ist das nur ein 6GB/s-Adapter, die Platten haben 12GB/s, aber hier darf ich wohl nicht wählerisch sein :)

Aktuell habe ich im "HP SmartStorageAdministrator" den Schreibcache für unkonfigurierte Platten aktiviert und die LogicalDrives gelöscht, so daß ZFS wieder die Platten "sieht".

Keine Ahnung, ob nun der Controller-Cache gemeint ist oder ob das einen Platten-Cache aktiviert. Auch habe ich keine Ahnung, ob das für ZFS "gesund" ist? Gebracht hat diese Einstellung jedenfalls nichts. Der nächste Versuch wird mit dem LSI sein.
 
Apr 13, 2016
16
0
6
Gestern Abend habe ich noch den M1015 zum 9211 umgeflasht (trotzdem Danke für den Link, allerdings fehlt bei diesem wie bei vielen anderen Anleitungen die benötigte megarec.exe - hier hat sie eine freundliche Seele in Beitrag #6 bereitgestellt: M1015.zip).

Ergebnis: Ebenso bescheiden wie mit dem HP-HBA, der somit rehabilitiert ist. Ich glaube immer mehr an unzählige Kopfbewegungen der Platten.

Nächster Versuch wird mit FreeNAS sein.
 

LnxBil

Famous Member
Feb 21, 2015
4,327
428
103
Germany
Ergebnis: Ebenso bescheiden wie mit dem HP-HBA, der somit rehabilitiert ist. Ich glaube immer mehr an unzählige Kopfbewegungen der Platten.
Wow ... da liegt echt was im argen. Ich verwende ZFS auf vielen System von ganz klein bis zu mehrere Shelves voller Platten und so langsam wie bei dir war noch kein ZFS bei mir. Ich bin echt gespannt wie die Performance von FreeNAS abschneidet, denn ZFS sollte auf der Hardware bedeutend schneller sein als deine Wiederherstellungsgeschwindigkeittests.
 

franz78

New Member
Oct 11, 2018
14
0
1
41
du kannst auch das neue zfs 0.8.2 mal probieren, bei mir hat das gerade im "write" jetzt einen boost gegeben.
 
Last edited:
Apr 13, 2016
16
0
6
Ich hatte zwischenzeitlich meine 3 vorhandenen Server wie folgt konfiguriert:
Server 1: Proxmox mit HW-RAID
Server 2: Proxmox ohne (genutzten) Datenplatten, über NFS eingebunden sind die Platten des
Server 3: FreeNAS 11.2 mit ZFS

Restore einer 80GB-vzdump Datei auf Server 1 (Zeit zwischen "100%" und "TASK OK" nur wenige Sekunden)
Code:
progress 98% (read 126272077824 bytes, duration 427 sec)
progress 99% (read 127560581120 bytes, duration 431 sec)
progress 100% (read 128849018880 bytes, duration 435 sec)
total bytes read 128849018880, sparse bytes 729341952 (0.566%)
space reduction due to 4K zero blocks 0.247%
rescan volumes...
TASK OK
Restore derselben vzdump-Datei auf Server 2
Code:
progress 98% (read 126272077824 bytes, duration 307 sec)
progress 99% (read 127560581120 bytes, duration 319 sec)
progress 100% (read 128849018880 bytes, duration 331 sec)
total bytes read 128849018880, sparse bytes 729341952 (0.566%)
space reduction due to 4K zero blocks 0.247%
rescan volumes...
TASK OK
aber während des Restore steigt "Writeback" auf -zig GB, die dann sehr langsam abgebaut werden, bevor "TASK OK" erscheint. Zu den angezeigten 330 Sekunden kamen nochmal ca 900 Sekunden dazu.

Außerdem zickte die Kombination Proxmox/FreeNAS dahingehend, daß NFS über die 10GB/s LAN-Karte sich aufhing. Das war aber nicht der Flaschenhals in dieser Geschichte, da schon die 1 GB/s-Leitung nicht gesättigt war.
 
Apr 13, 2016
16
0
6
...also alles wieder in die Ausgangsposition:

Nochmals in die Systemeinstellungen des HP P816-Controllers, dort nochmals in die Einstellungen für den Schreibcache und alles aktivieren, was geht, außerdem die Platten unkonfiguriert lassen, damit sie an das OS durchgereicht werden.
Innerhalb von Proxmox ein ZFS aufgebaut. Nun ist die Schreibperformance endlich OK und erreicht mehrere hundert MB/s.

Ich vermute weiterhin, daß bei HPE das "Command Queueing" der Platten/des Controllers nicht ordnungsgemäß funktionieren, mit dem Zugriffe auf die Platten in einer sinnvollen Reihenfolge ausgeführt werden sollen. Ich bin mit dem Ergebnis erst einmal zufrieden und werde einige wenige Echtdaten hinüberziehen und gucken wie es sich verhält.
 

michaeljk

Member
Oct 7, 2009
58
1
8
Durch die aktivierten Caches dürfte man aber einen guten Teil der Sicherheit verlieren, den ZFS eigentlich bieten soll. Sofern der Controller meldet, dass die Daten bereits weggeschrieben wurden, sich aber noch in irgendeinem Cache im System befinden, so wäre dies bei einem Absturz oder Stromausfall nicht unbedingt günstig. Wir hatten leider auch in der Vergangenheit negative Erfahrungen bei HP-Systemen in Verbindung mit ZFS machen müssen, das gleiche System ohne ZFS und direkt über Hardware-RAID + LVM läuft hingegen problemlos.

Was mich etwas wundert ist, das auch der Speed über den M1015 noch nicht besser gewesen sein soll (zumindest im Vergleich zum integrierten HP-Controller ohne aktivierte Caches). Ich würde das an deiner Stelle nochmal mit einer zusätzlichen, anständigen Enterprise SSD (ZIL) durchtesten.
 
Apr 13, 2016
16
0
6
Durch die aktivierten Caches dürfte man aber einen guten Teil der Sicherheit verlieren, den ZFS eigentlich bieten soll.
"So what?" wäre ich geneigt zu sagen...
Die Frage ist lediglich, ob es durch den Cache SCHLIMMER werden kann als als HW-RAID. Selbst mit aktiviertem Cache bleiben die Features wie Prüfsummenbildung, schnellerer RAID-Aufbau, Replikation, direkte SMART-Abfragen,...
Sofern der Controller meldet, dass die Daten bereits weggeschrieben wurden, sich aber noch in irgendeinem Cache im System befinden, so wäre dies bei einem Absturz oder Stromausfall nicht unbedingt günstig.
Das ist wohl so, aber damit könnte ich aufgrund von batteriegepuffertem Cache des HP-Controllers und vorhandener USV auch noch leben. Dieselben Nachteile hätte ich schließlich auch bei HW-RAID. Wiederum stelle ich mir die Frage: Wird es schlimmer als HW-RAID durch aktivierten Cache?
Wir hatten leider auch in der Vergangenheit negative Erfahrungen bei HP-Systemen in Verbindung mit ZFS machen müssen, das gleiche System ohne ZFS und direkt über Hardware-RAID + LVM läuft hingegen problemlos.
Nur eben ohne Prüfsummenbildung, Komprimierung, evtl. Dedup, Replikation, evtl ist nicht einmal RAID 6 möglich (bei mir geht nur RAID-5 mit allen seinen Gefahren oder aber RAID-10 bzw RAID-50 mit erheblichen Kapazitätseinschränkungen)
Was mich etwas wundert ist, das auch der Speed über den M1015 noch nicht besser gewesen sein soll (zumindest im Vergleich zum integrierten HP-Controller ohne aktivierte Caches).
Was mich wundert, war daß hdparm -W /dev/sd? auswarf, daß dieses Feature nicht unterstützt sei. Mir fehlt jetzt der Vergleich zu anderen Systemen, aber wenn die Platten keinerlei Schreibcache besitzen und dann evtl auch nicht einmal die Schreibzugriffe in sinnvolle Reihenfolge bringen (COMMAND QUEUEING), dann braucht man sich über nichts zu wundern.
Ich würde das an deiner Stelle nochmal mit einer zusätzlichen, anständigen Enterprise SSD (ZIL) durchtesten.
Genau das halte ich für die Tests für nicht sinnvoll, denn es nützt mir nichts, die Performance der SDD zu testen. Hier ist (schon jetzt) absehbar, was passieren würde: Die Daten landen auf der LOG-SSD, was solange schnell geht, wie dort noch Platz ist. Danach bricht die Performance gnadenlos ein, denn dann sind mehrere hundert GB ganz ganz langsam auf die Platten zu schreiben.
(ist ja auch nicht so, daß ich das nicht probiert hätte. Schließlich war das mein erster Versuch, als ich noch davon ausging, man könnte einen Server im Wert eines neuen Kleinwagens einfach einsetzen - naja, eigentlich war es mein zweiter Versuch, denn ursprünglich wollte ich CEPH nutzen. Damit war die Performance aber auch schon extrem ernüchternd, nur hatte ich mich da nicht auf die Ursachensuche gemacht.)

Tut zwar nichts zur Sache, aber würde man mich fragen, könnte ich vom HPE DL380 G10 nur abraten (er war ein paar Euronen billiger als der von mir bevorzugte TK-Server, also wurde der gekauft). Eigentlich sehr schön aufgebaute Hardware, ILO-Management macht auch Spaß, aber zuerst funktionierten die Broadcom 10 GB/s-LAN nicht, so daß INTEL-basiertes nachgekauft werden mußte, nun die Probleme mit dem HDD-Subsystem. Wenn irgendwann zusätzliche Steckkarten eingebaut werden müssen, muß ein zusätzliches Riser-Board (auch nicht gerade umsonst) nachgekauft werden, zudem heulen die Lüfter schon bei relativ geringer Last los, ziemlich nervig für diejenigen im Nachbarbüro. Insgesamt werden die Kisten teurer werden als das was ich haben wollte - recht geschieht der GL. :)
 

LnxBil

Famous Member
Feb 21, 2015
4,327
428
103
Germany
Genau das halte ich für die Tests für nicht sinnvoll, denn es nützt mir nichts, die Performance der SDD zu testen. Hier ist (schon jetzt) absehbar, was passieren würde: Die Daten landen auf der LOG-SSD, was solange schnell geht, wie dort noch Platz ist. Danach bricht die Performance gnadenlos ein, denn dann sind mehrere hundert GB ganz ganz langsam auf die Platten zu schreiben.
So funktioniert das ZIL aber nicht: https://www.ixsystems.com/blog/zfs-zil-and-slog-demystified/

Tut zwar nichts zur Sache, aber würde man mich fragen, könnte ich vom HPE DL380 G10 nur abraten (er war ein paar Euronen billiger als der von mir bevorzugte TK-Server, also wurde der gekauft). Eigentlich sehr schön aufgebaute Hardware, ILO-Management macht auch Spaß, aber zuerst funktionierten die Broadcom 10 GB/s-LAN nicht, so daß INTEL-basiertes nachgekauft werden mußte, nun die Probleme mit dem HDD-Subsystem. Wenn irgendwann zusätzliche Steckkarten eingebaut werden müssen, muß ein zusätzliches Riser-Board (auch nicht gerade umsonst) nachgekauft werden, zudem heulen die Lüfter schon bei relativ geringer Last los, ziemlich nervig für diejenigen im Nachbarbüro. Insgesamt werden die Kisten teurer werden als das was ich haben wollte - recht geschieht der GL. :)
Nachbarbüro? Habt ihr Racks in den Büros stehen?
Generell sind das feine Kisten, mit denen wir bisher noch 0 Probleme hatten und wir haben Hardware von allen großen und einigen kleinen Herstellern im Einsatz - aber auf sehr wenigen ZFS. Die meisten hängen einfach mit simplem RAID1 an einem SAN dran und verrichten seit vielen, vielen Jahren ihren Einsatz. Wir haben sogar noch G5 im Einsatz und die laufen seit mehr als 10 Jahren und tun's heute immer noch
 
Apr 13, 2016
16
0
6
Kannte ich schon, habe es aber trotzdem nochmals durchgelesen. Ein "kleines" Detail, das mir beim ersten Lesen entfing, ist mir hier nochmals klar geworden: Jeder Schreibvorgang (natürlich gilt das bei jedem Journaling Filesystem) passiert ohne SSD auf einer reinen HDD zweimal, einmal im LOG, einmal an der endgültigen Stelle. Damit ist eine miese Performance bei reinem HDD-Betrieb doch schon quasi unvermeidlich, wenn nicht gecacht wird. Wie soll es denn anders als mit unzähligen Kopfbewegungen gehen? Ist das LOG auf einer separaten Platte, wird der zweite Schreibvorgang auf der HDD entbehrlich.

Nachbarbüro? Habt ihr Racks in den Büros stehen?
Klimatisierter Serverraum mit Büros nebenan. So riesig ist die Firma nicht...
(Mein Büro ist glücklicherweise hinreichend weit weg, so daß das ein PAL ist ..)

Generell sind das feine Kisten, [...]
Stimmt. Ich äußerte mich ja auch nicht negativ zur allgemeinen Qualität. Aber hier ist ein Proxmox-Forum, und da erscheint die Hardware nicht optimal zu sein. Schon daß die 10 GB/s-Adapter nicht mit Debian-Kerneln neueren Datums funktionieren, ist ziemlich lästig. Beim Hersteller findet man Treiber zum Kernel 2.6.xx. Unterstützt wird RedHat und Windows, sonst nix. Vielleicht wird das mit dem Erscheinen von RedHat 8 ja besser, da da ja auch ein neuerer Kernel dabei ist. Mit TK und IBM (x3650M???) hatte ich deutlich weniger Trouble.
 

LnxBil

Famous Member
Feb 21, 2015
4,327
428
103
Germany
Kannte ich schon, habe es aber trotzdem nochmals durchgelesen. Ein "kleines" Detail, das mir beim ersten Lesen entfing, ist mir hier nochmals klar geworden: Jeder Schreibvorgang (natürlich gilt das bei jedem Journaling Filesystem) passiert ohne SSD auf einer reinen HDD zweimal, einmal im LOG, einmal an der endgültigen Stelle. Damit ist eine miese Performance bei reinem HDD-Betrieb doch schon quasi unvermeidlich, wenn nicht gecacht wird. Wie soll es denn anders als mit unzähligen Kopfbewegungen gehen? Ist das LOG auf einer separaten Platte, wird der zweite Schreibvorgang auf der HDD entbehrlich.
Ja, das ist vor allem interessant, da jeder synchrone Schreibzugriff der randomisiert auf der Platte erfolgt erstmal synchron sequentiell ins Log geschrieben wird. Worauf der Artikel nur am Rande eingeht ist, warum nur ein kleiner Cache benötigt wird: Es werden maximal 5 Sekunden ins Log geschrieben, dann wird dieses auf die Platten geflusht und da du keine mehreren Gigabyte da pro Sekunde reinhauen kannst, benötigt man nur ein sehr, sehr kleines SLOG. Sämtliche sequentiellen, großen Datenstreams gehen eh komplett am SLOG (und am ARC) vorbei.

Mir ging es hauptsächtlich um diese zwei Sätze:

Hier ist (schon jetzt) absehbar, was passieren würde: Die Daten landen auf der LOG-SSD, was solange schnell geht, wie dort noch Platz ist. Danach bricht die Performance gnadenlos ein, denn dann sind mehrere hundert GB ganz ganz langsam auf die Platten zu schreiben.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!