[Sammelthread] ZFS Stammtisch

Das "ex" ist hier lediglich die Abkürzung für Example und kein Programmaufruf.

Das Script muss per Scriptname (muss dann ausführbar sein) oder per sh scriptname aufgerufen werden.
In letzterem Fall muss das Script lediglich lesbar sein.

Ich denke aber dass "export" für Scripte die wie hier mit at now im Hintergrund gestartet werden nicht funktioniert.
Man muss also zfs list in eine Variable schreiben oder als Datei z.B. nach /tmp schreiben um es später wieder einzulesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hallo gea,

Danke für das schnelle Feedback.
Das "ex" hatte ich in der Hilfe als "Kommando" zum Ausführen (EXecute) interpretiert, nicht als Abkürzung für EXample :-)

"export" war noch ein Relikt aus einer Vorversion des Scripts, allerdings erhalte ich ohne "export" (also: CURRENT_SNAP=$(zfs list -t snapshot | grep $source_pool@$source_job | tail -1) ) die gleiche Fehlermeldung (zfs: not found). Den Umweg über eine Datei würde ich gerne vermeiden - daher die Frage, ob du noch einen Tipp hast, was hier verkehrt läuft?
 
zfs not found

Da passiert wenn /sbin nicht im Pfad ist und zfs daher nicht gefunden wird.
Statt "zfs list" "/sbin/zfs list" aufrufen.
 
Es ist allgemein best practice in Skripten den komplett Pfad zu verwenden. Die Nicht-Konsolenshell Umgebung ist oft eine andere als die der Konsolenshell. Idealerweise einmal alle executables zu Beginn einmal definieren, dann fällt der Wechsel auf eine neue Plattform oder auf geänderte Pfade nicht so schwer, z.B:

#!/bin/bash
ZFS=/sbin/zfs
ZPOOL=/sbin/zpool

$ZFS list
$ZPOOL list

Welcher Pfad der richtige ist, bekommst mittels which, z.B.
which bash
 
Mal ne doofe Frage:

Ich kopiere große Dateien auf meinem Mirror Pool aus 2x 12TB IronWolfs.
Der RAM (64GB) füllt sich, aber wird nie wieder frei - ist das richtig so?
 
Unbenutzter RAM ist unnützer RAM. Wenn andere Prozesse RAM benötigen, wird der wieder frei gemacht.

Edit: Insofern: Ja, das ist normal. Bei Virtualisierung stört das manchmal etwas weil u.U. der erste Start einer VM wegen zu wenig RAM fehlschlägt. Dann kannst Du je nach OS die Obergrenze anpassen. Proxmox bedient sich z.B. teilweise auch etwas sehr großzügig.
 
Zuletzt bearbeitet:
Alles klar.

Heute morgen habe ich diese Meldung in der Konsole bekommen - das zweite Mal jetzt.
fmadm list zeigt das unten angehängte.
Dabei lief der Kopiervorgang von rund 3TB aus dem Netzwerk auf den Plattenpool.

Die VM wurde dabei ebenfalls neugestartet

Code:
--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Sep 07 08:03:53 d5e31380-55a9-489d-9975-806b10f3a405  SUNOS-8000-KL  Major

Problem Status            : open
Diag Engine               : software-diagnosis / 0.2
System
    Manufacturer          : unknown
    Name                  : unknown
    Part_Number           : unknown
    Serial_Number         : unknown

System Component
    Manufacturer          : VMware, Inc.
    Name                  : VMware Virtual Platform
    Part_Number           :
    Serial_Number         : VMware-42 27 4e 73 7a 16 38 8e-9d 95 e8 6f 4c 8e 8a 0f
    Firmware_Manufacturer : Phoenix Technologies LTD
    Firmware_Version      : (BIOS)6.00
    Firmware_Release      : (BIOS)12.12.2018
    Host_ID               : 0047e763
    Server_Name           : *hostname*

----------------------------------------
Suspect 1 of 1 :
   Problem class : defect.sunos.kernel.panic
   Certainty   : 100%
   Affects     : sw:///:path=/var/crash/data/d5e31380-55a9-489d-9975-806b10f3a405
   Status      : faulted but still in service

   Resource
     FMRI             : "sw:///:path=/var/crash/data/d5e31380-55a9-489d-9975-806b10f3a405"
     Status           : faulty

Description : The system has rebooted after a kernel panic. The following are
              potential bugs.
              stack[0] - 27580105 15685395 18328400

Response    : The failed system image was dumped to the dump device.  If
              savecore is enabled (see dumpadm(8)) a copy of the dump will be
              written to the savecore directory
              /var/crash/data/d5e31380-55a9-489d-9975-806b10f3a405.

Impact      : There may be some performance impact while the crash dump is
              copied to the savecore directory.  Disk space usage by crash
              dumps can be substantial.

Action      : If savecore is not enabled then please take steps to preserve the
              crash image. Use 'fmdump -Vp -u
              d5e31380-55a9-489d-9975-806b10f3a405' to view more panic detail.
              Please refer to the associated reference document at
              [url]http://support.oracle.com/msg/SUNOS-8000-KL[/url] for the latest
              service procedures and policies regarding this diagnosis.

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Sep 06 22:03:26 c1f19410-46dd-45f9-89b5-bef336cfe609  SUNOS-8000-KL  Major

Problem Status            : open
Diag Engine               : software-diagnosis / 0.2
System
    Manufacturer          : unknown
    Name                  : unknown
    Part_Number           : unknown
    Serial_Number         : unknown

System Component
    Manufacturer          : VMware, Inc.
    Name                  : VMware Virtual Platform
    Part_Number           :
    Serial_Number         : VMware-42 27 4e 73 7a 16 38 8e-9d 95 e8 6f 4c 8e 8a 0f
    Firmware_Manufacturer : Phoenix Technologies LTD
    Firmware_Version      : (BIOS)6.00
    Firmware_Release      : (BIOS)12.12.2018
    Host_ID               : 0047e763
    Server_Name           : *hostname*

----------------------------------------
Suspect 1 of 1 :
   Problem class : defect.sunos.kernel.panic
   Certainty   : 100%
   Affects     : sw:///:path=/var/crash/data/c1f19410-46dd-45f9-89b5-bef336cfe609
   Status      : faulted but still in service

   Resource
     FMRI             : "sw:///:path=/var/crash/data/c1f19410-46dd-45f9-89b5-bef336cfe609"
     Status           : faulty

Description : The system has rebooted after a kernel panic. The following are
              potential bugs.
              stack[0] - 27580105 15685395 18328400

Response    : The failed system image was dumped to the dump device.  If
              savecore is enabled (see dumpadm(8)) a copy of the dump will be
              written to the savecore directory
              /var/crash/data/c1f19410-46dd-45f9-89b5-bef336cfe609.

Impact      : There may be some performance impact while the crash dump is
              copied to the savecore directory.  Disk space usage by crash
              dumps can be substantial.

Action      : If savecore is not enabled then please take steps to preserve the
              crash image. Use 'fmdump -Vp -u
              c1f19410-46dd-45f9-89b5-bef336cfe609' to view more panic detail.
              Please refer to the associated reference document at
              [url]http://support.oracle.com/msg/SUNOS-8000-KL[/url] for the latest
              service procedures and policies regarding this diagnosis.

Hatte das schon mal jemand?
Wie kann ich das Problem angehen?
Bzw was ist dort überhaupt das Problem?
 
Ich frage mich eben ob es eine bemerkbare Leistungssteigerung bringt von 6* SATA6 WD RED 8TB RAIDZ2 auf 6* SAS12 Seagate Exos E 7E8 8TB RAIDZ1 zu wechseln? (oder andere SAS12 Platten)

Ich bin günstig an einen ASUS PIKE II gekommen und der ist ja für SATA überdimensioniert...
Die Platten kosten gut die Hälfte mehr, haben aber doppelte MTBF und längere Garantie, deshalb würde ich von RAIDZ2 auf Z1 wechseln.

Meinungen?
edit: die 7E8 sind archive, also ungeeignet, ich muss noch nach den richtigen suchen und Preise raussuchen
edit2: 7E8 sind doch die guten, 5E8 sind Archive
edit3: irgendwie hab ich 8 festplatten geschrieben, sind aber nur 6 und auch 6 geplant...
 
Zuletzt bearbeitet:
Raidz1 bei 6 HDDs finde ich schon nahezu Russisch Roulette. Zwei RaidZ1 mit 3 HDDs vdevs in einem Pool fände ich da besser.


Wie sind eigentlich eure Erfahrungen bezüglich von consumer HDDs bzw NAS-HDDs in Servern mit 12 Platten? Stören bzw beschädigen die Vibrationen die Platter stark? Meine Wechselrahmen sind nicht nennenswert entkoppelt.
 
OK, nochmal "zfs best practice" gegoogeled, ab 6 disks ist raidz2 angesagt (dann habe ich zumindest diesen punkt mit meinem system bis jetzt richtig gemacht)

da ich "demnächst" meine Festplatten wegen Alter tauschen möchte frage ich mich ob ich bei besagten wd red bleibe oder auf "bessere" sas Platten wechsele.
also sind SAS Laufwerke bei gleichem raidz2 viel schneller? so 150% Preis-schneller?

Die Kapazität müsste noch etwas reichen, auch es wenn dank snapshots (von vms und backups) nur aufwärts gehen kann.

Ich denke auch nicht das ein cache so viel bringt, außer eventuell für die vm-vdisks die auch da drauf liegen.
 
Es gibt Festplatten, die gibt es in Sata und SAS Ausführung. Die sind dann in der Regel gleich schnell. SAS hat dann den Vorteil der robusteren Datenübertragung, der größeren möglichen Kabellänge und Multipath (zwei Anschlüsse) für Cluster/ HA Setups.

Erst bei 12G SAS SSDs wie WD Ultrastar SS530 spielt SAS performancemäßig in einer anderen Liga als Sata.

- - - Updated - - -

Hatte das schon mal jemand?
Wie kann ich das Problem angehen?
Bzw was ist dort überhaupt das Problem?

Ist das Solaris 11.4?

Prinzipiell kann man jetzt noch das System Log anschauen. Ein Crash/Kernel Panic kann entweder durch einen Software Bug oder Treiber/Hardware Problem ausgelöst werden.

Wenn man die freie "Demo/Entwickler" Version von Solaris 11.4 nutzt, so gibt es keinen Support oder Bugfixes von Oracle. Man kann dann allenfalls im Oracle Solaris Forum schauen oder fragen, Space: Solaris 11 |Oracle Community
 
ok, dann bleibe ich wohl bei SATA. (macht sinn das die gleiche Platte nicht plötzlich viel schneller wird wenn n anderes interface dran ist)
Es bringe wohl mehr statt der normalen red die red pro zu benutzen, die haben zwar auch nur 1M MTBF aber 7.2k statt der 5.2k rpm der normalen.

Oder welche Platten werden hier so verwendet, gibt es da Favoriten?
 
Ich würde mir da wohl die seagate Exos anschauen. gibt es als sata und sas. Haben 5 Jahre Garantie und sind günstiger als die wd red pro und haben 2 M mtbf.

Ich würde wohl die SAS nehmen - wenn man schon einen entsprechenden HBA hat, kann man auch von den erweiterten Features ggü. Sata profitieren.
 
Zuletzt bearbeitet:
Hab die WD HC530 (=Wurzeln in der HGST He-Serie) mit Sata und 512emulation in einem Raidz2-Pool mit 6 Platten. Die Teile waren neben der Kapazität ein massives Performance-Upgrade insbesondere bei Random-Access ggü. den Deskstar Nas 6TB (welche auch 7200er sind). "Massiv" heisst hier: nicht Prozent sondern Faktoren schneller.
 
Zuletzt bearbeitet:
Hallo gea

Du, auf Deiner Website unter download ist das Dokument napp-in-one.pdf irgendwie nicht mehr erreichbar. Stimmt mit dem Link irgendwas nicht?
 
Ich brauche mal kurz Input bezüglich ZFS und SSDs:

Ich habe für LAN-Partys einen Dell R610 (Intel E5530, 48GB RAM, 10GBit Ethernet und Dell H310 im IT-Mode) mit Proxmox für Infrastruktur wie Gameserver und LANCache. Dieser läuft momentan mit 5x 146GB SAS 10k HDDs im RAIDZ1. Eine einzelne 512er Samsung 840 Pro mit ext4 hab ich derzeit für den Lancache im Einsatz.

Platz und Performancetechnisch reicht mir das allerdings nicht mehr aus, der drehender Rost soll rausfliegen und die Kiste all-Flash werden. Angedacht sind 3 Mirrors-vdevs mit je 2 SSDs, ~400GB pro Mirror.

Sollte ich hier eher auf gebrauchte Enterprise-SSDs setzen (Falls ja, welche sind da empfehlenswert?) oder kann ich in dem Anwendungsfall auch Consumer-SSDs nehmen?
Datensicherheit ist eher unwichtig, die Kiste kommt nur ein paar mal pro Jahr im Einsatz und die VMs sind extern gesichert. daher würde ich gerne so wenig wie möglich (aber so viel wie nötig) ausgeben.
 
gibts in Freenas eigentlich irgendwo nen Indikator ob Disks im Spindown sind? Bei Unraid sieht man das ja schön aber bei Freenas hab ich da irgendwie noch nix zu finden können...
 
Zuletzt bearbeitet:
Ich brauche mal kurz Input bezüglich ZFS und SSDs:

Ich habe für LAN-Partys einen Dell R610 (Intel E5530, 48GB RAM, 10GBit Ethernet und Dell H310 im IT-Mode) mit Proxmox für Infrastruktur wie Gameserver und LANCache. Dieser läuft momentan mit 5x 146GB SAS 10k HDDs im RAIDZ1. Eine einzelne 512er Samsung 840 Pro mit ext4 hab ich derzeit für den Lancache im Einsatz.

Platz und Performancetechnisch reicht mir das allerdings nicht mehr aus, der drehender Rost soll rausfliegen und die Kiste all-Flash werden. Angedacht sind 3 Mirrors-vdevs mit je 2 SSDs, ~400GB pro Mirror.

Sollte ich hier eher auf gebrauchte Enterprise-SSDs setzen (Falls ja, welche sind da empfehlenswert?) oder kann ich in dem Anwendungsfall auch Consumer-SSDs nehmen?
Datensicherheit ist eher unwichtig, die Kiste kommt nur ein paar mal pro Jahr im Einsatz und die VMs sind extern gesichert. daher würde ich gerne so wenig wie möglich (aber so viel wie nötig) ausgeben.

Schau mal im Marketplace von STH oder so, hier z.B. ein gutes Angebot: Enterprise ssd up to 16TB | ServeTheHome and ServeThe.Biz Forums
oder Intel 800GB DC P3700 SSD PCIE SSD $200 | ServeTheHome and ServeThe.Biz Forums
Würde auf gebrauchte Enterprise SSDs setzen, die haben einfach eine gleichbleibende Geschwindigkeit und halten vermutlich länger als neue Consumer SSDs.
 
Was ist denn der performanteste Weg, sechs Platten á 1TB in einem Pool zusammenzufügen? Ca 3TB sollten (mindestens) dabei raus kommen.
Drei Mirror Pärchen und darüber ein Stripe oder?
 
Hallo,

ich beschäftige mich seit einigen Wochen mit ZFS, genauer: Mit der Implementierung ZFSonLinux und Proxmox.

Mir sind da leider massive Performance-Probleme aufgefallen, wo ich nicht weiß wo die herkommen. Mir ist bewusst das ZFS wesentlich Hardware-hungriger ist und das ich nicht die selbe Performance wie bei einem LVM erwarten kann. Aber eine ordentliches Arbeiten sollte schon irgendwie möglich sein.

Zwei identische Nodes, einer mit ZFS Mirror (root on ZFS, Standardinstallation, compression=lz4, ashift=12, 50% RAM für ARC) und einer mir LVM (drunter Raid1 mdadm) und ext4 - mit folgender Hardware:

CPU Intel Xeon E5-2620 v3
RAM 32GB
Mainboard Supermicro X10SRH-CLN4F

Anfangs bei beiden Nodes jeweils zwei Samsung SM863 SSDs. Angeschlossen am HBA vom Mainboard (LSI3008). Mit vzdump schaffte ich beim LVM-Node 220MB/s schreiben, während ich beim ZFS-Node maximal 82MB/s schaffte. Mehr als 50% weniger Schreib-Durchsatz, dass kann doch eigentlich schon nicht sein. Kopieren auf einen Fileserver-Container aus dem Netzwerk ebenfalls 82MB/s. Also: ich kann nicht mal ein Gigabit-Netzwerk auslasten. Auch bei fio kamen bei 4K write mit Sync fürchterliche ERgebnisse raus. Teilweise nur mit 14MB/s schreiben, bei gerade mal einem Job mit 1Gb.

Danach entschied ich mich aufzurüsten und das Proxmox OS auf zwei seperate SSDs mit LVM, Raid1 und ext4 auszulagern. Für die Container und VMs nahm ich nun vier Intel D3 SSDs und bildete aus denen ein ZFS Raid10 mit den gleichen Einstellungen wie oben, nur das ich diesmal manuell die atime=off selbst setzen musste. Bei keinen Daten und laufenden VMs, also jungfräulich, ergab fio folgende Werte:

Code:
fio --name=/rpool/testfile --ioengine=libaio --iodepth=32 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --group_reporting
/rpool/testfile: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.12
Starting 1 process
/rpool/testfile: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=216MiB/s][w=55.3k IOPS][eta 00m:00s]
/rpool/testfile: (groupid=0, jobs=1): err= 0: pid=25570: Thu Sep 12 00:43:10 2019
  write: IOPS=37.0k, BW=145MiB/s (152MB/s)(1024MiB/7081msec); 0 zone resets
    slat (usec): min=5, max=103661, avg=25.07, stdev=533.98
    clat (usec): min=2, max=108397, avg=838.16, stdev=3240.21
     lat (usec): min=12, max=108437, avg=863.39, stdev=3297.83
    clat percentiles (usec):
     |  1.00th=[   265],  5.00th=[   277], 10.00th=[   289], 20.00th=[   314],
     | 30.00th=[   351], 40.00th=[   400], 50.00th=[   465], 60.00th=[   545],
     | 70.00th=[   635], 80.00th=[   766], 90.00th=[  1090], 95.00th=[  1549],
     | 99.00th=[  7570], 99.50th=[ 12780], 99.90th=[ 39060], 99.95th=[103285],
     | 99.99th=[106431]
   bw (  KiB/s): min=72181, max=248040, per=98.63%, avg=146056.57, stdev=56510.07, samples=14
   iops        : min=18045, max=62010, avg=36514.07, stdev=14127.57, samples=14
  lat (usec)   : 4=0.01%, 20=0.01%, 50=0.01%, 100=0.01%, 250=0.15%
  lat (usec)   : 500=54.52%, 750=24.22%, 1000=9.41%
  lat (msec)   : 2=8.15%, 4=1.61%, 10=1.23%, 20=0.49%, 50=0.16%
  lat (msec)   : 100=0.01%, 250=0.07%
  cpu          : usr=7.08%, sys=58.63%, ctx=16917, majf=0, minf=9
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=145MiB/s (152MB/s), 145MiB/s-145MiB/s (152MB/s-152MB/s), io=1024MiB (1074MB), run=7081-7081msec

152MB/s... das kann doch nicht das Ende der Fahnenstange sein, oder? Der Witz war: Als ich dann wieder verschiedene Container per Restore auf den pool gebracht habe, ging der Durchsatz wieder auf 82MB/s runter. Egal ob fio, kopieren aus dem Netzwerk oder vzdump.

Kann mir jemand einen Tipp geben, was ich noch tun könnte? Oder ist das wirklich alles?

Bin mit meinem Latein am Ende. Mit Raid10 hätte ich so mindestens bei 200MB/s erwartet, wenn paar Container laufen und es nur minimale Schreibzugriffe gibt.

Gruß
 
Ich arbeite selbst eher weniger mit Debian.

Grundsätzlich ist ZFS, vor allem mit wenig RAM langsamer als z.B. ext4. Das liegt vor allem daran, dass ZFS Prüfsummen zu Daten und Metadaten anfügt (mehr Daten zum lesen/schreiben), dazu vergrößert CopyOnWrite die Fragmentiering (ist dafür Crash sicher) und ZFS verteilt die Datein gleichmäßig über das Raid (steigert Performance mit Anzahl der vdevs, dafür gibt es keine rein sequentielle Transfers, iops wird entscheidend). Ausgleichen, ja überkompensieren kann man das mit RAM. das ja bei ZFS neben read- auch als write Cache genutzt wird um aus vielen langsamen random writes wenige schnelle sequentielle Wites zu machen.

Grundsätzlich würde ich bei schlechter ZFS Write Performance
- sync für das Dateisysten auf "disabled" stellen um das Problem einzukreisen

und dann überlegen, ob man sicheres Schreiben braucht.
Ansonst RAM für ZFS so weit wie möglich vergrößern und bei Bedarf für sicheres sync Write ein schnelles Slog (Optane > 800P, WD Ultrastar SS DC 530 etc) dem ZFS Pool hinzufügen
 
Zuletzt bearbeitet:
@gea, plane demnächst einen zweiten SSD Pool anzulegen (4x im Stripe),
a.) taugen dafür die Intel DC P4510 ?
b.) wie läuft das mit dem RAM ab, wenn ich auf einem OS 2 Pools hab, kann ich irgendwie forcieren, das mein Pool aus SAS Platten mehr RAM als Cache bekommt als der SSD Pool ? Oder einfach alles Solaris machen lassen ?
 
Allen Intel Datacenter SSD vertraue ich was "sicheres Schreiben" angeht (powerloss protection).
Beim Lesen von "wahlfeien" Reads zählt eh nur ZFS Arc caching mit > 80% Trefferquote bei ausreichend RAM.

Bei der Schreibperformance kommt es auf 4k write iops ind latency an.
Man kann den Vergleich zu den schnellsten Intel ziehel (Optane ab 800p).

Die haben 10 us Latency und 500k write iops.
Langsame Intel DC haben 70us latency und 50k iops.

Das max Arc read caching begenzt den genutzten System RAM, nicht das Caching einzelner Pools - wirkt eh nicht bei sequential read, arbeitet daher auch bei mehreren Pools sehr gut.
 
Grundsätzlich würde ich bei schlechter ZFS Write Performance
- sync für das Dateisysten auf "disabled" stellen um das Problem einzukreisen

und dann überlegen, ob man sicheres Schreiben braucht.
Ansonst RAM für ZFS so weit wie möglich vergrößern und bei Bedarf für sicheres sync Write ein schnelles Slog (Optane > 800P, WD Ultrastar SS DC 530 etc) dem ZFS Pool hinzufügen

Ich geh mal davon aus, dass du mit sync disabled für Dateisystem, die Option meinst:

Code:
zfs set sync=disabled POOL

Muss man das für den kompletten Pool anwenden, oder kann man das auch für einzelne Datasets setzen?

Ich habe mir mal die WD DC S530 angesehen und ich denke das es diese werden wird. Für eine Optane bräuchte ich eine M.2 oder U.2-Schnittstelle, die das X10SRH-CLN4F noch nicht hat. Dafür kann ich die WD mit 12Gb/s über die Backplane verwenden.

Muss ein SLOG möglichst redudant sein, also im Raid1 oder reicht eine? Was passiert wenn mitten im Betrieb das SLOG ausfällt? Muss dann sync wieder enabled werden?
 
Zuletzt bearbeitet:
M2/U2 kannst ja günstig mit Adaptern in nen PCIE-Slot nachrüsten, eine Optane als SLOG ist absolut zu empfehlen. Die Latenzen sind einfach unerreicht.

Sync geht per Dataset einzustellen.

Wenn das Slog als extra Device ausfällt, wird AFAIK bei aktiviertem Sync auf den Datendevices weiter geloggt, denn ein ZIL gibts ja immer bei ZFS. Und verloren ist auch nix an Daten, da ein Slog ja nur beschrieben wird, aber nur im Fall des Falles gelesen. Ist ja kein Write-Cache.
 
M2/U2 kannst ja günstig mit Adaptern in nen PCIE-Slot nachrüsten, eine Optane als SLOG ist absolut zu empfehlen. Die Latenzen sind einfach unerreicht.

Habe tatsächlich einen passenden Adapter gefunden: Supermicro AOC-SLG3-2M2. Firmen wie DeLock oder Startech vertraue ich leider nicht, dann wären die Adapter auch nochmal günstiger.

Hier wurden ja die Optane 800P schon erwähnt. Im Vergleich zu den WD sind die aber in den reinen Werten, auch bei IOPS lesen/schreiben, deutlich schlechter. Welches Modell wäre denn da genau empfehlenswert? Gibt ja eine riesige Auswahl. In die engere Auswahl würde eventuell noch die Optane SSD DC P4801X fallen. Die ist sogar leicht besser als die WD
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh