[Sammelthread] ZFS Stammtisch

Ich suche gerade vier M.2 2280 PCIe SSDs mit je 4TB für ein raidz1.

Die SSD soll kein Cache haben und Sync Write soll aktiviert bleiben.

Problem:
- Es gibt in der Größe nix mit Power-Loss-Protection
- Die meisten haben DRAM cache - und das nicht zu knapp, teilweise mehrere GB
- Es gibt einige mit SLC-Cache (der ja persistent ist), aber so ganz ohne flüchtigen Cache arbeiten die dann scheinbar doch nicht. Die, die ich mir rausgesucht hatte, arbeiten dann halt mit HBM, also dem Arbeitsspeicher vom PC als Cache. Toll.

Wie ist denn da bei solchen SSDs die Strategie, um Datenverlust im Fall von Stromausfall und ähnlichem zu vermeiden?

Kann man HBM irgendwie deaktivieren? Und wenn der SLC als einziger Cache genutzt wird, sind die controller von solchen SSDs schlau genug, um den SLC-Cache in den richtigen Flashspeicher zu flushen, sobald der Strom wieder da ist?

Oder ist das alles gar nicht so problematisch?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Sync Write auf Flash ohne PLP ist blöd.
SSD werden aber immer besser was powerloss angeht, halt ohne Gewähr wenn der Hersteller es nicht garantiert

Mögliche Auswege

Slog z.B. Intel Optane 1600 oder andere ev gebraucht
Damit wäre sync logging sicher, andere Probleme sollte ZFS im Raid gering halten.

U.2/3 statt M.2

schnelle SAS Laufwerke statt M.2

UPS um das Risiko zu verringern
 
Weil die Zugriffszeiten extrem schlecht werden. Wenn die SSD erst den tatsächlichen Schreibvorgang committen muss => Langsam. Wenn sie das "commit" faked für schnellere Zugriffszeiten, dann sind die Daten in Gefahr wenns Dir den Strom wegzieht.

SSDs ohne Cache "Bantha Poodoo"-mässig lahm. Das siehst Du an den Billo-SSDs mit QLC-Flash und ohne Dram-Cache. Sobald der SLC-Cache voll, bricht die Datenrate sowas von grandios sein. unter 100MB/s Sequentiell ist dann keine Seltenheit, random i/o ist dann auch "gaga". Das kann bei Verwendung als Systemlaufwerk bis zum Stottern des Systems führen.
Wolltest Du da auch keinen HBM zulassen: willkommen in der SSD-Steinzeit bzgl. Geschwindigkeit.
SSDs müssen cachen, weil Du nicht Byte für Byte im Flash beschreiben kannst, sondern große Blöcke ansprechen musst. Und die muss der Controller erst löschen, und dann wieder beschreiben. Dauert.

M.2 wirst Du Datacenter-grade mit PLP kaum finden, schlicht weil das Format für Datacenter relativ unpraktisch ist: Kühlung schlecht, rumschrauben im laufenden Server statt Hotplug., begrenzte Kapazität.

Alternative: hol Dir Optane 3D-Xpoint, die haben das alles nicht. Aber Du zahlst Dich krum und buckelig für Kapazität.


Und bzgl. Deiner Idee, Platten rotierend bewusst aus nem Raidz2 zu ziehen: sorry, das ist eine absolute BS-Idee, bewusst den Pool zu degraden.
Wenn Du den Strom für eine HDD sparen willst, dann go raidz1 und nicht raidz2.
Ferner: kauf nicht die größten HDDs, die sind pro TB Kapazität immer am teuersten ! Mit 18 oder 20TB Laufwerken fährst Du in aller Regel deutlich preiswerter.
 
Zuletzt bearbeitet:
Das Problem geht tiefer als als nur ein Dram Schreibcache. Mit Trim und Garbage Collection finden im Hintergrund Datenbewegungen statt. Auch da darf nichts passieren. SSD werden zwar immer besser und Probleme damit geringer, nichts desto weniger gilt: Was nicht draufsteht ist nicht drin. Ist wie bei Urlaubsreisen. Meerblick ohne Aufpreis gibt es nicht oder nur im November wenn das Hotel leer ist.

PLP bedeutet konstruktiven Aufwand und den sparen sich die Hersteller gerne oder versuchen nur mit Firmwareoptimierung das Problem in den Griff zu bekommen. Meist wird damit aber nur das kritische Zeitfenster kleiner in dem der Strom nicht ausfallen sollte oder die SSD unter Last recht langsam, https://www.kingston.com/en/blog/servers-and-data-centers/ssd-power-loss-protection

Die einzige NVMe die ziemlich sicher PLP kann ohne dass es in den Specs steht ist die Intel 800er Optane Serie. Als die auf den Markt kam war PLP noch garantiert, dann entschied Intel dass die eher was für Gamer sei und Firmen doch bitte die teure 4800er kaufen sollen die nahezu identisch ist aber 4x so teuer war.

Sync Write bei dem man den Inhalt des RAM Schreibcaches sichern möchte und dadurch eh massive Performanceeinbrüche in Kauf nimmt, macht in besonderm Maße nur Sinn wenn das auch sicher funktioniert. Sonst kann man sync auch bleiben lassen und hat ein viel schnelleres System.
 
Zuletzt bearbeitet:
Inwieweit da meine Optane p1600x als slog (sync always) für mein zfs mirror im PVE, welche keine PLP haben, Sinn gibt, ist ja auch etwas fraglich - je nachdem wie kritisch man das sehen mag.
 
Digitale Prozesse sind immer sequentiell und manche Prozesse dürfen nie nur teilweise erfolgen. Ist nicht so wie bei einem Lichtschalter wo alle Lampen gleichzeitig an oder ausgehen. Bei einer Risikobetrachtung macht es aber schon einen großen Unterschied ob mehrere Sekunden Write z.B. ein 4GB ZFS Writecache verloren geht oder ein paar Hundert KB eines Raid-Stripes über 2-8 Platten in der kritischen Zehntelsekunde nur teilweise geschrieben werden oder ob wenige Zeiger beim Aktivieren eines ZFS Copy on Write Datenblocks in der kritischen Zehntausendstel Sekunde nur teilweise geschrieben werden konnten.

Ein Pool mit SSD ohne PLP mit einem Optane 1600 zum Sichern des Schreibcaches macht daher schon Sinn. Raid Fehler kann ZFS entdecken und reparieren und der Inhalt des Schreibaches ist mit Optane sicher. Unvollständig geschriebene Raid Stripes wie bei traditionellem Mirror oder Raid 5/6 kennt ZFS nicht und Fehler beim Copy on Write Aktualisieren sind so wahrscheinlich wie ein Dachziegel der einem bei schönem Wetter auf den Kopf fällt.

Absolute Sicherheit gibt es nicht, nur Risikominimierung und Fahrlässigkeit.
 
Ich habe Mal ne Frage zum Thema "Backup/Wiederherstellung testen"

Und zwar nutze ich Snapshot Replication, von einem TrueNAS auf ein anderes TrueNAS.

Die Stand der Snapshots ist bei beiden NAS gleich, soweit so gut.

Jetzt würde ich aber gerne auch ab und zu Testen ob die Daten auf dem Backup NAS auch wiederherstellbar sind.

Wie würdet ihr da vorgehen?
Per CLI in den Snapshot gehen und die Daten dort Prüfen?
Die Daten auf einen externen Datenträger wiederherstellen und dort prüfen?

Oder gibt's eine bessere Möglichkeit?
 
Um auf ein Snapshot zuzugreifen, brauchts kein Restore.

Unter OmniOS ist der einfachste Weg Windows Previous Versions. (Windows Explorer > Eigenschaft eines Ordners >Vorherige Version) Bei Solaris/OmniOS und dem ZFS/kernelbasierten SMB Server muss man für ZFS Snaps=previous Versions nichts konfigurieren da SMB Shares und Snaps Eigenschaften eines ZFS Dateisystems sind. Mit SAMBA muss man bei der Konfiguration aufpassen da SAMBA nur einfache Ordner sieht, ohne Bezug zu ZFS Dateisystemen und Snaps.

Alternativ
Snaps liegen im Ordner /pool/dateisystem/.zfs/snapshots

Alternativ
Einen Clone eines Snaps anlegen. Ein Clone kann man lesen und beschreiben, ein Snap ist readonly.
 
Mal eine Frage zu ZFS on Windows

Die Snapshots tauchen nicht als Vorgängerversion auf oder? Das ist ein OmniOS Feature oder?
 
Einen Clone eines Snaps anlegen. Ein Clone kann man lesen und beschreiben, ein Snap ist readonly.
Ready Only reicht mir ja schon um die Daten prüfen zu können.

Danke für den Tipp, das sollte bei TrueNAS Ruckzuck machbar sein.
Den Inhalt der Snapshots kann ich mir notfalls über die CLI anschauen.

Die replizierten Snapshots liegen auf dem Backupnas, welches keine Shares hat.

Das Ding wacht zu einer definierten Uhrzeit auf, repliziert die Snapshots per Pull und legt sich wieder schlafen. Reines Backup
 
Mal eine Frage zu ZFS on Windows

Die Snapshots tauchen nicht als Vorgängerversion auf oder? Das ist ein OmniOS Feature oder?

Das ist ein Feature das der SMB Server können muss.

OmniOS/Solaris kann das einfach mit den kernel/ZFS SMB Server.
SAMBA sollte das auch können wenn man SMB sehr sorgfältig konfiguriert
Windows Server kann das (nicht mit ZFS)
Windows 10/11 kann das nicht
ZFS on Windows kann das (noch) nicht
https://github.com/openzfsonwindows/openzfs/issues/350

eventuell gehts schneller wenn man da Interesse an dem Feauture bekundet
 
In diesem Script wird das beispielhaft gelöst (basierend auf `zfs-auto-snapshot`, einem tool, dass lokale Snapshot-Verwaltung automatisiert):

https://github.com/bashclub/zamba-l...ab2/src/zmb-standalone/install-service.sh#L37
Ich hatte mehrfach versucht einen Windows SMB Server durch SAMBA unter Linux abzulösen.
Am Ende habe ich es aufgeben. Nicht nur wegen ZFS Snaps als Vorherige Version, mehr noch wegen der miserablen Umsetzung von Windows ntfs ACL. Je mehr man das versucht, desto kompizierter wird es, ohne jemals anständig zu funktionieren. Der einzige Unix SMB Server der das halbwegs hinbekommt und dabei eher noch einfacher zu konfigurieren ist als ein Windows Server ist der kernel/ZFS SMB Server von Solaris und den Solaris Forks.

SAMBA ist ok wenn man einem Windows Zugang zu Linux verschaffen möchte, am einfachsten anonym mit Vollzugriff oder nur basierend auf einfachen Unix Permissions.
 

Release Notes for OmniOSce v11 r151050l (2024-07-23)​

Weekly release for w/c 22nd of July 2024, https://omnios.org/releasenotes.html


This update requires a reboot

Security Fixes​

  • AMD CPU Microcode updated to version 20240710.

Other Changes​

  • The compatibility copy of the PCI IDs file in /usr/share/pci.ids.gzdelivered by pkg://system/pciutils/pci.ids was mistakenly empty. This filehas been removed and the same package now provides a symbolic link from/usr/share/pci.ids to /usr/share/hwdata/pci.ids to support softwarewhich incorrectly assumes the wrong location.
 
Hi, ich will auf meinem Proxmox-Server1 (V8.2.4 mit Kernel 6.8.12-1-pve, zfsutils-linux: 2.2.4-pve1) eine neue Media-Bibliothek für Emby(Proxmox-Server2) in Betrieb nehmen.
Heißt im Grunde nur mehrere GB-große Dateien hauptsächlich, das kleinste dürften diverse Audiobooks mit ebenfalls zweistelligen bis dreistelligen MB-größen pro Datei.
HW-Plattform ist das Gigabyte MC12-LE0 aus dem Thread nebenan, mit einem Ryzen 5600 und 64GB 3200er ECC Kingston, die Platten hängen nativ am Board-SATA, kein HBA.

Habe mir bei Mindfactory 2x 20TB MG10ACA20TE (512e statt 4kn) Platten günstig geholt, ohne zu schauen ob 512e oder 4k nativ.

Wie, also welche ZFS-Optionen/Flags, sollte ich daraus nun am klügsten einen Mirror erstellen?
 
512E und 4kn sind beides physical 4k Platten, erstere halt mit einem optionalen 512B Emulationsmodus z.B. für ein altes OS.
ZFS ist das egal. Wenn man nicht 512B/ashift 9 erzwingt, wird beidesmal automatisch 4k benutzt (ashift 12).

Probleme gabs nur früher mal mit einzelnen 4k Platten der ersten Generation die sich fälschlicherweise mit 512B physical/logical gemeldet hatten.
 
Hi

Laufen napp-it und xigmanas nach dem Start komplett im RAM? Die liegen im Moment auf dem ESXi auf einer noname billig SSD. Bekomme jetzt noch eine kleine SM883. Macht es Sinn, die Filer da drauf zu verschieben? Oder spielt das keinen Rugel?

Und wieviel RAM macht bei napp-it im AiO Mode ohne SW RAID Sinn? Hängen zwei 1.92 TB SM883 für die VMs und eine 8 TB WD RED dran. Im Moment habe ich 22 GB zugewiesen. Würde noch mehr was bringen?

Gruss und danke
 
Die Napp-it web-gui ist eine cgi Applikation. Das bedeutet dass lediglich beim Aufruf eines Menüs das entsprechende Script aufgerufen wird. Ansonst werden nur Jobs und Logs gelesen/geschrieben.

Im Hintergrund läuft ein Webbserver. Dessen Last ist aber gering da kein PHP oder eine SQL Datenbank benutzt wird. Eine aktuelle Speicherbelegung bei einem 3GB RAM System unter ESXi sieht z.B. so aus

Code:
root@omnios:~# echo ::memstat | mdb -k
Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                     830341              3243   26%
Boot pages                    137                 0    0%
ZFS File Data             2118128              8273   67%
Anon                        38565               150    1%
Exec and libs                1566                 6    0%
Page cache                   6899                26    0%
Free (cachelist)            14917                58    0%
Free (freelist)            132997               519    4%

Total                     3143550             12279
Physical                  3143549             12279
root@omnios:~#

Wie man sieht ist der Speicherbedarf extrem gering.
Acceleration und Monitoring erzeugen zusätzlich etwas Hintergrund Last.

Insgesamt gilt bei OmniOS

OS: 1-2 GB RAM
ZFS Lesecache: bis zu ca 70% RAM
ZFS Schreibcache: max 4GB/10% RAM

Unter ESXi mit pass-through wird der zugewiesene RAM fest zugeordnet. Es gibt also keine Überraschung wenn ein anderer Prozess kurzfristig mehr RAM möchte und ZFS den nicht schnell genug freigibt.

Eine OmniOS Storage VM geht sehr gut ab 4GB RAM vor allem mit NVMe weil man da den Cache nicht so braucht. Mit langseameren Platten bringt der RAM Schreib/Lesecache Cache Performance. Mit Arcstat kann man prüfen wie hoch die hitrate ist. Da sieht man schnell ob mehr RAM was bringt. Mit 22 GB ist man aber bereits gut dabei. Mehr RAM kann noch was bringen, aber keinen großen Zuwachs.

Ein Aspekt wäre noch powerloss protection für das ESXi boot device. Das bringt noch Sicherheit. Eine SM883 wäre da sehr gut.
 
Zuletzt bearbeitet:
Ja, bekomme nun von einem Luxxer 3x 240 GB SM883. Dann gehen Host, die beiden Filer sowie die Xigmanas Datenplatte auch noch auf Datacenter Hardware. Die liegen im Moment auf drei Consumer SSD.

Dann sollte mein Server von Consumer Hardware befreit sein. Bis auf das Gehäuse, premium Netzteil, die Lüfter und das DVD Laufwerk; die dürfen bleiben. Aber die Kiste verdient bald den Namen Server, obwohl ich sie schon seit 2010 rum liebevoll so nenne.
 
Zuletzt bearbeitet:
Ein paar neue Ideen für napp-it cs (BSD, Linux, Solaris and Windows) und ZFS encryption

Create ZFS filesystems:

- mit 256sha-hex für keys (keine Konfusion mit oO0iIlL characters in Keys)
- sha256 hash aus kurzem einfach zu merkendem pw als key

https Keyserver
- Apache on Windows oder company/university webserver und public certificates
- passphrase und ip range protected

3way Keysplit (je > 20 char)
- distribute keyparts zwischen localem ZFS server und/oder webserver w1 oder w2
- HA/ failover falls w1 or w2 offline
- unlock mit verteilten keyparts oder direct via key oder simple/short pw
- key overview local/w1/w2

https://www.napp-it.de/doc/downloads/napp-it cs encryption.pdf
 
Die nächste Open-ZFS Version 2.2.6 ist verfügbar

Die Changelist errinnert mich aber an die "Windows DLL Hell" Problematik, hier bezogen auf die vielen Linux Distributionen, jede mit eigener ZFS Release und Updatemöglichkeiten. Da lobe ich mir doch nach wir vor Illumos und Solaris wo man das Problem nicht hat.

Der neueste Open-ZFS für Windows pre-release candidate 1 kommt bereits mit 2.2.6 und neben Raid-Z Expansion zusätzlich mit Fast Dedup und den neuesten Dedup Commits dieser Woche.

Jorgen Lundman, Maintainer von Open-ZFS on Windows hat allerdings die komplette mount/unmount/volume Integration neu geschrieben um das besser in Windows integrieren zu können. Da gibt es aktuell noch Probleme z.B. mit mount und export die sicher sehr schnell behoben werden.

Fast Dedup könnte aber das Killerfeature werden, das Dedup wegen vieler Probleme nie werden konnte. Ich gehe davon aus, dass man Fast Dedup künftig per default in den meisten Fällen aktivieren kann so wie jetzt Compress.

https://github.com/openzfsonwindows/openzfs/releases

https://openzfs.org/wiki/Main_Page (Vorstellung von Fast Dedup)
 
Zuletzt bearbeitet:
Ich bleibe da bezügl. (Fast)Dedup wenig enthusiastisch, nicht wegen Performance, sondern wegen mangelnder Dedup-Rate. Die typischen Blockgrößen bei virt. Windows Maschinen auf ZVOLS erlauben keine allzu gute Trefferquote identischer Blöcke. Das würde mit 512 Bytes sicher anders aussehen, das führt aber an anderen Stellen zu Problemen.

zdb -S pool ermöglicht seit langem eine ganz gute Übersicht, ob sinnvoll oder nicht, daran verbessert Fast Dedup ja offenbar nichts.

cu
 
Das ist dann wie bei Compress. Es gibt Fälle da bringt das nix weil die Daten bereits komprimiert sind. Entscheidend ist eher dass man Fast Dedup in den meisten Fällen genauso wie Compress einfach aktivieren kann und es hat dann außer einem einstellbaren Mehrverbrauch von RAM (DDT_Quota) keinen großen Nachteil. In vielen Fällen spart es aber ordentlich Platz und reduziert io was natürlich auch die Performance verbessern kann.
 
Naja Compress hat doch den Vorteil glaub dass die Dateien nicht mehr an die Sektorgrenze aligned werden müssen oder?
 
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