[Sammelthread] ZFS Stammtisch

[gea]

der Solaris SMB Server speichert die ACLs ja im Dateisystem so wie ich das verstanden habe. Aber wie läuft das normal unter Samba, wo werden die da gespeichert. Sind die wenn ich die Festplatten mit den Daten in ein anderes System stecke einfach weg? Oder gibts irgendeine Datei die Samba da anlegt wo alles drin gespeichert ist?

Bei einem Vergleich Samba vs Solaris CIFS sollte man von Windows und ntfs ausgehen.
Windows arbeitet mit Usergruppen die Gruppen oder User enthalten können. Die Identifizierung der User oder Gruppen erfolgt mit eindeutigen Windows Security IDs (SID) die eine Domänen oder Serverkennung enthalten.

Mit diesen SID Kennungen kann man auf einem NTFS Datenträger ACL anlegen. Windows ACLs sind sehr mächtig. Damit lassen sich nicht nur Rechte sondern auch Rechtevererbungen sehr fein einstellen. Man kann dadurch festlegen dass eine ACL z.B. nur für einen Ordner oder auch untergeordnete Ordner oder Dateien wirken soll.


Wenn man jetzt statt NTFS ein Unix Dateisystem benutzt, so ist das erste Problem, dass Unix als Security Kennung UID und GID benutzt. Beides ist eine einfache Nummer ohne Bezug zu einer Domäne oder einem Server. Hinzu kommt dass Unix Gruppen keine Gruppen enthalten können, sie also weniger Optionen haben als Windows Gruppen. Hinzu kommt, dass es unter Unix unterschiedliche Dateisysteme mit unterschiedlichen Fähigkeiten gibt.

Damit ist auch bereits das Hauptproblem von Samba beschrieben. Es ist ein universeller SMB Server für Unix (BSD, Solaris) und Linux. Die features orientieren sich an dem, was immer zur Verfügung gestellt wird. Damit gibt es nur Unix UID und GID. Bei den ACL werden üblicherweise Posix ACL benutzt. Im Vergleich zu Windows ACL oder NFS4 ACL unter Solaris fehlen die feinen Einstellmöglichkeiten und Vererbungsoptionen.

Die (Posix) ACL werden bei Samba auch im Dateisystem gespeichert sofern das Dateisystem das zulässt und Samba entsprechend konfiguriert wird. Als Bezug gibt es aber nur Unix/Linux UID und GID. Die Zuordnung zu einem Windows User z.B, in einer Domäne erfolgt über ein Usermapping SID <-> UID/GID. Wenn man ein Dateisystem dann auf einen anderen AD-Server verschiebt, so bleiben die Permissions nur erhalten, wenn man genau die gleiche Samba Konfiguration mit identischem Mapping hat.


Solaris CIFS arbeitet da etwas anders. Da es das nur auf Solaris und -Forks und nur mit ZFS gibt, kann es sich erheblich besser an Windows orientieren. Das fängt damit an, dass der Solaris CIFS Server eine Windows-kompatible Gruppenverwaltung hat, die unabhängig von Unix Gruppen die erweiterten Fähigkeiten von Windows hat. Um die UID/GID Beschrängunken des Unix Dateisystems ZFS bei SMB zu umgehen, speichert Solaris die originale Windows SID für Domaänenuser als erweitertes ZFS Attribut. Es gibt zwar auch ein Usermapping Windows User <-> Unix User, das braucht man aber lediglich für spezielle Mappings wie Domänenadmin=root. Wird unter Solaris/ OmniOS ein Dateisystem auf einen anderen AD Server verschobe, so bleiben die AD Rechte erhalten, ohne dass etwas beachtet werden muss.
Als ACL werden bei Solaris nfs4 ACL benutzt. Die sind sehr ähnlich zu Windows ACL, unterscheiden sich vor allem in den deny Regeln bei denen die ACL Reihenfolge wichtig ist.

Eine weitere Besonderheit von Solaris ist die Integration von SMB in den Kernel und in ZFS. Das erleichtert dann sowas wie ZFS Snaps als Windows "vorherige Version" erheblich. Ein Grund warum das bei Solaris "einfach tut" und bei Samba erheblichen Aufwand bedeutet.

 

[skelleton]

Wobei jetzt der Snapshot support im Samba auch nicht mehr so ein riesiger aufwand ist, da es Projekte gibt die es genau das implementieren.
Und Samba beherrscht bei entsprechender Konfiguration rfc2307 ldap Erweiterungen bei denen das uid/gid->Windows User/Gruppe Mapping direkt im Active Directory gespeichert wird.
Fuer die standard Fileserver Szenarien reicht das von Samba angebotene ACL Mapping aus.

Aber insgesamt lief bei meinem Solaris ZFS System mehr out of the box als bei ZFSonLinux + Samba (ich habe mit dem Solaris System aber auch Napp-It genutzt und keine Verschluesselung implementiert).
Und ZFSonLinux ist immer noch nicht so ausgereift

 

[besterino]

ZFSonLinux ist sicherlich frickeliger und (leider) funktioniert nicht alles so sensationell simpel wie mit Solaris(-Fork)+Napp-it. Aber: bei mir - zugegeben nur mit moderater Home-Use-Last - absolut stabil und inklusive "Windows vorherige Version"-Snapshots.

 

[millenniumpilot]

Hallo,

vielleicht interessant oder neu für den Einen oder Anderen.

http://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-not-raidz/

 

[besterino]

Och scheisse... jetzt muss ich vielleicht doch nochmal über mein Pool-Layout nachdenken. Insbesondere das Thema "expand later" ist schon interessant und hatte ich in meinen Überlegungen ausgeklammert nach dem Motto "wenn voll, dann kommt eh was ganz neues". Ich würde mit 50% meiner aktuellen Rohkapazität heute - und auch auf absehbare Zeit in der Zukunft (wahrscheinlich 1-2 Jahre) - locker hinkommen.

 

[millenniumpilot]

expand later ist mein aktuelles Problem, daher bin ich auf jenen Blog gestoßen.
Mein auf Kapazität getrimmtes Z2 aus 10 Platten ist Rappelvoll und falls jetzt der Vorschlag kommt, löschen der Schmuddelfilme ist keine Lösung ;-)
Gleichzeitig 10 neue Platten kaufen (meinetwegen HGST 6TB a 260€) und sukzessive zu tauschen bis zum Poolexpand, fällt aus Kostengründen aus. Auch ein zweites neues vdev aus 6 Platten ist kaum drin. Es sei denn, ich wähle dazu eigentlich nicht mehr zeitgemäße 2 TB-Platten.
Mal schnell einen kleinen Mirror als zusätzliches vdev hinzufügen ist für den kleinen Privatmann leichter zu verkraften. Es tut zwar wegen dem Verschnitt beim Erstellen eines Pools aus Mirror-vdevs weh, aber später....
Die im Blog genannten Argumente und Zahlen beim Resilvern sind auch nicht ohne.

 

[TCM]

Falls das alles nur Filme u.ä. sind, wäre SnapRAID die bessere Wahl gewesen.

 

[millenniumpilot]

Falls das alles nur Filme u.ä. sind, wäre SnapRAID die bessere Wahl gewesen.

das war ein Joke, da großer Pool oft mit Pornosammlung assoziiert wird.

 

[ludwinator]

Also grundsätzlich mal kann ich jeden Pool erweitern, egal ob er aus Mirror oder RAIDZx gebaut wurde.
Ob das empfehlenswert ist, hängt halt vom Einsatzzweck und den Ansprüchen ab.
Erweiterung eines vollen Mirrors mit einem weiteren ist auch nicht das gelbe vom Ei, weil ein re-balancing bekanntlich nicht stattfindet.
Die sauberste (und schnellste) Lösung bei Platzmangel (abgesehn vom löschen) ist für mich immer noch ein zusätzlicher Pool (Mirror oder RAIDZx), bestehend aus aktuellen Platten (möglichst groß, je nach Geldbeutel und Anforderung). Dorthin dann per zfs send/recv einzelne FS rüberschieben.

cu

 

[CommanderBond]

Ist es denn wirklich so dass beim Resilvern bei einem RaidZx vdev auf allen Platten auch geschrieben wird?

Verstehe nicht so ganz was der Typ auf seinem Blog schreibt, oder vielleicht sehe ich es teilweise nur anders.

Wenn man von 6 Platten ausgeht, einmal als RaidZ2, ein vdev, und dann als 3 vdevs jeweils als Mirror.
Wenn ich nen Mirror mit mehreren vdevs habe sollte man bedenken dass bei einem zweiten Ausfall schon alles hin sein kann, wenn eben die Platte in dem gleichen vdev auch ausfällt. (3way Mirror sind wohl für die wenigsten eine Option)

Wenn beim Resilvern wirklich Daten GESCHRIEBEN werden auf allen Platten, ist es natürlich besser wenn man dann einfach zfs send von dem degradeden pool auf einen neuen macht.

 

[ludwinator]

Geschrieben wird nur auf die Platten, die ersetzt werden. Aber es muss von allen gelesen werden, das dauert einfach deutlich länger. Ist auch viel Random Read dabei im Gegensatz zu nem Mirror.
Dazu passt auch ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZ - Matt Ahrens (hab ich glaube ich schon mal gepostet in diesem Thread).

cu

 

[Bzzz]

Zum ersten Link:

RAIDZ2 and RAIDZ3 try to address this nightmare scenario by expanding to dual and triple parity, respectively. This means that a RAIDZ2 vdev can survive two drive failures, and a RAIDZ3 vdev can survive three. Problem solved, right? Well, problem mitigated – but the degraded performance and resilver time is even worse than a RAIDZ1, because the parity calculations are considerably gnarlier. And it gets worse the wider your stripe (number of disks in the vdev).

Halt ich für Panikmache, über das bisschen Parity lächelt ne heutige CPU doch nur müde. Limit ist zudem immer die Datenrate, mit der die zu ersetzende Platte schreiben kann, und die wird mit steigender Zahl Platten in nem vdev auch nicht größer oder kleiner.
Mittlerweile haben wir im Heimbereich quasi flächendeckend AES-NI, sodass man ne Poolverschlüsselung für nahezu umsonst draufhauen kann. Und die Sparc T5 hashen doch auch schon mit Hardwarebeschleunigung, oder?

Mirror vdev resilvering goes really quickly, with very little impact on the performance of the pool.

Aber auch nicht mehr quickly als die Platte halt kann. Klar, man spart sich das Berechnen und Schreiben der Parity bzw. der daraus rekonstruierten Daten, man kopiert halt nur. Dafür steht das Quelllaufwerk unter Volllast, während bei nem RAIDZ sagen wir 5 Platten diese einzelne füttern müssen. Die haben dann nochn bisschen Zeit, um andere Dinge zu tun.

The only disk more heavily loaded than usual during a mirror vdev resilvering is the other disk in the vdev – which might sound bad, but remember that it’s only being heavily loaded with reads, whereas all of the remaining disks in a RAIDZ vdev are being much more heavily loaded with writes as well as reads during a resilver. Resilvering a mirror is much less stressful than resilvering a RAIDZ.

+

Geschrieben wird nur auf die Platten, die ersetzt werden. Aber es muss von allen gelesen werden, das dauert einfach deutlich länger. Ist auch viel Random Read dabei im Gegensatz zu nem Mirror.

ZFS weiß, wo die Daten liegen. Wieso wird das bei nem RAIDZ mit Random I/Os gemacht, und bei nem Mirror schnurrt er sequentiell drüber? Kann mir das jemand erklären? Meine Vorstellung ist, dass reihum gelesen wird, und entweder das fehlende Häppchen Daten rekonstruiert wird, oder die Parity neu berechnet wird (je nachdem, was auf der ausgefallenen Platte lag). Wo muss da auf die nicht betroffenen Laufwerke was geschrieben werden? gea weiß das bestimmt

Let’s say you had a server with 12 slots to put drives in, and you put six drives in it as a RAIDZ2. When you bought it, 1TB drives were a great bang for the buck, so that’s what you used. You’ve got 6TB raw / 4TB usable. Two years later, 2TB drives are cheap, and you’re feeling cramped. So you fill the rest of the six available bays in your server, and now you’ve added an 12TB raw / 8TB usable vdev, for a total pool size of 18TB/12TB. Two years after that, 4TB drives are out, and you’re feeling cramped again… but you’ve got no place left to put drives. Now what?
[...]
What if you’d used mirror vdevs? Well, to start with, your original six drives would have given you 6TB raw / 3TB usable. So you did give up a terabyte there. But maybe you didn’t do such a big upgrade the first time you expanded. Maybe since you only needed to put in two more disks to get more storage, you only bought two 2TB drives, and by the time you were feeling cramped again the 4TB disks were available – and you still had four bays free

Und wenns heute nur Diskettenlaufwerke gäbe, dann hätte man eh nicht so viel speichern können, und dann wärs noch schneller gegangen? Also sorry, was ist das denn für ne Rechnung. Z1 6x1 + 6x2 gegen gemirrorte 2x1 + 2x1 + 2x1 + 2x2 + 2x4...und dann wundern, dass man im Array mit mehr Platten öfter tauschen muss? Die ersten drei Mirrors mit den ältesten, langsamsten Disks sind knallvoll und die neuen liegen brach, aber Mirroring ist das Allheilmittel? Und kann ZFS mit nem Ausfall beim Mirror-Replace eigentlich umgehen, indem die grade noch funktionierende Platte wieder (unterbrechungsfrei) reingeholt wird?

 

[gea]

Es gibt viele Gründe, etwas so oder anders zu machen. CPU oder Disk Belastung würde ich aber nicht als Grund für das eine oder andere sehen. Das bisschen Raidberechnung ist eh vernachlässigbar sofern die CPU besser ist als die aus einem aktuellen Billig Smartphone. Die Ausfallrate von Platten ist zudem relativ unabhängig von der Belastung. Manche Seagate 3 TB überlebt kaum 2 Jahre egal ob durch Nichtstun oder Vollast. Meine HGST haben wohl Ausfallraten von 3-5% pro Jahr, egal ob im Hauptfiler oder im sekundären Backup der nur nachts ein bisschen Last hat. Spätestens nach 5-7 Jahren sollte man Platten eh ersetzen.

Mirror nur wegen der Erweiterbarkeit oder schnellerem Resilver zu nehmen und dafür 50% Platz zu verlieren ist wenig sinnvoll. Viele Mirrors wegen der besseren iops Leistung wäre eher ein Plan. In Zeiten schneller SSDs wird aber das auch obsolet. Zudem ist mir bei einem Z2 wohler, da zwei beliebige Platten ausfallen dürfen.

Das Hauptproblem der fehlenden Erweiterbarkeit hat man vor allem wenn man z.B. nur 16 Bays hat und das mit einem single vdev Raid-Z2/3 Pool füllt. Ich mache das dann so, dass ich in meinen Backup Maschinen mehrere Raid-Z2 vdevs einbaue. Geht der Platz zur Neige ohne dass Platz für ein weiteres vdev ist, ersetze ich in einem vdev die Platten durch größere und zwar nicht indem ich eine Platte herausnehme und dadurch die Redundanz schwäche, sondern in dem ich die kleineren durch größere ersetze. Erst wenn die neue eingebunden ist, nehme ich die alte dann inaktive heraus. Das führt zwar zu Perfomanceeinbußen da der Pool zunächst unbalanced ist. Das gleicht sich aber mit der Zeit aus oder ich kopieren ein Dateisystem per zfs send lokal um wenn ich darauf nicht warten möchte.

Für High-Performance Pools ist das aber keine Option aber die werden eh voll aufgerüstet gekauft und bei Bedarf komplett ersetzt.

 

[CommanderBond]

Mittlerweile haben wir im Heimbereich quasi flächendeckend AES-NI

Ihr (du) vielleicht schon aber "wir" ganz sicher nicht. Intel ziert sich da immer noch sehr um dieses Feature grade im LowEnd Bereich. Ich mein viele haben den Microserver G7 oder Gen8, der kann das ebenso nicht wenn man nicht grad nen Xeon drin hat.
AES-NI gibts erst am der Mittelklasse bei Intel. Zumindest ist mir keine billig CPU bekannt (50euro) die sowas drin hat.

 

[Bzzz]

Intel ziert sich auch bei ECC...

Naja jedenfalls ist ein Prozessor mit AES-NI zu haben, wenn man darauf Wert legt. Bei AMD grundsätzlich bei jedem FM2+/FM2, oder falls man ECC möchte auch auf jedem AM3+ (alle neu ab ~50€), lustigerweise sogar bei den AM1-Kabinis. Bei Intel halt für 100 Eier aufwärts über alle aktuellen und halb-aktuellen Normalo-Plattformen hinweg, außer man will auf den 2011er (dann für alle Prozessoren, aber halt 300€++). Wenn man andererseits aber keine 50€ für ne CPU übrig hat, dann weiß ich nicht wieviel man in RAM oder Platten stecken möchte. Und dann braucht man sich auch nicht über das ein oder andere rausgekitzelte MB/s bei der Wahl von dieser oder jener Konfiguration seines ZFS unterhalten, denn für ein paar lausige Euro mehr kriegt man noch massive Performanceschübe, rein durch vorher per Geiz oder falsch aufgeteiltes Budget verursachte Flaschenhälse.
Also verstehs nicht falsch, meine Kiste ist auch durchaus ein Budget-Bau. Aber auch deswegen wurds halt ein AMD-System mit nem FX-6300 und nem BR10i, weil ich auch die nächsten Jahre nicht mehr als 2TB pro Port brauche. Und der FX langweilt sich durchgängig, wenn ich heute nochmal wählen könnte würds ein 4000er werden. Vielleicht sogar, wenn ich heute von Null aus neu bauen müsste. Wenn man halt das Neueste vom Neuesten haben muss oder andere abgefahrene Anforderungen hat, dann lässt sich das immer wer bezahlen. Aber das schießt am Low-End-Gedanken vorbei, wer nicht mehr ausgeben kann/darf/will, der muss halt schlauer zusammenstellen als jemand, der einfach nur Geld drauf werfen kann, bis es was wird.

 

[Rahvin]

vielleicht interessant oder neu für den Einen oder Anderen.
ZFS: You should use mirror vdevs, not RAIDZ. | JRS Systems: the blog

Ich finde diesen Blog Post zu einseitig. Es geht nur um Performance, nicht um ein Abwägen zwischen Performance und Zuverlässigkeit.

Das Zitat von ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZ - Matt Ahrens ist wohl bewusst zu kurz gewählt.

... For even better performance, consider using mirroring.
For best reliability, use more parity (e.g. RAIDZ3 instead of RAIDZ1)...

Der Zweite Satz ist für mich der entscheidende: bei RAIDZx können x beliebige Platten ausfallen und die das Filesystem ist noch verfügbar.

 

[millenniumpilot]

Hallo,

ich danke für alle Antworten von Usern, welche sich mehr damit auskennen und den Blog kritisch gelesen haben.

 

[ludwinator]

Zum ersten Link:

...

ZFS weiß, wo die Daten liegen. Wieso wird das bei nem RAIDZ mit Random I/Os gemacht, und bei nem Mirror schnurrt er sequentiell drüber? Kann mir das jemand erklären? Meine Vorstellung ist, dass reihum gelesen wird, und entweder das fehlende Häppchen Daten rekonstruiert wird, oder die Parity neu berechnet wird (je nachdem, was auf der ausgefallenen Platte lag). Wo muss da auf die nicht betroffenen Laufwerke was geschrieben werden? gea weiß das bestimmt

...

Ich versuchs mal zu erklären. ZFS weiß welcher Sektor belegt ist und womit, daher müssen auch nur belegte Sektoren kopiert werden.
Hier mal ein Beispiel wie das auf den Platten (hier 9) aussehen könnte:

1 2 3 4 5 6 7 8 9
D D D X D D D D P
D P D D D D X D D
D D X X D D D P D
X D D X D D P D D
D D D P D D X D D
D D D D D P D D D
P D D X D D D D D

D sind Daten, P ist Parity, X ist unbelegt.
Wenn also Platte 1 ausfällt, müssen 2,3 und 5-9 gelesen und gerechnet werden um das fehlende D wiederherzustellen.
Das sind keine Blöcke, sondern Sektoren (512B oder 4k). Jede Zeile im Beispiel hält also max 4kb oder 32kb Nutzdaten, um einen Block von 128k komplett zu lesen brauchts schon 32 oder 4 Zeilen.
Dank CoW müssen die gefragten Sektoren aber keineswegs hintereinander auf den Platten liegen, das kann (und wird) ganz schön verstreut sein. Jede Zeile gilt erst als erledigt, wenn alle Sektoren gelesen wurden.
Bei nem Mirror wird einfach jeder belegte Sektor gelesen und auf den Partner kopiert, das läuft praktisch sequentiell.


cu

 

[Bzzz]

Oookay, und ZFS traut sich nicht, den vielen RAM zu nutzen, um Zeug sequentiell einzulesen und dann aber nur das zu benutzen, was tatsächlich grade gebraucht wird? Man macht Häppchen für Häppchen mit Random I/O fertig, und sammelt dann aber ZFS-typisch für 5 Sekunden, bis mans möglichst sequentiell rausschreibt?

Bleiben wir mal bei deinem Datensatz und nehmen das als Grundlage für nen Mirror. Leerstellen sind jetzt leer, Parity existiert nicht.

Außer wenn ich die randvolle 5 spiegeln möchte, müsste man für jede der anderen Platten doch wieder häppchenweise transferieren, ganz blöd z.B. bei der 7. Oder wird da doch wieder sequentiell "einfach alles" kopiert?

1 2 3 4 5 6 7 8 9
D D D   D D D D  
D   D D D D   D D
D D     D D D   D
  D D   D D   D D
D D D   D D   D D
D D D D D   D D D
  D D   D D D D D

 

[gea]

Es gibt da durchaus Unterschiede zwischen Solaris und OpenZFS wie das Resilvering gehandhabt wird.
https://blogs.oracle.com/roch/entry/sequential_resilvering

 

[trendco]

Kurze Frage zwischendurch: Ich brauche für einen zweiten ZFS Mirror-Pool zwei 256GB SSD's.
Die kommen in meinen Proxmox-Homeserver als Datastore für 4-5 Windows VM's.
Könnt Ihr mir da aus Erfahrung was empfehlen? (Keine Highend Profi-Teile, sollen gut & günstig sein

 

[Bzzz]

Es gibt da durchaus Unterschiede zwischen Solaris und OpenZFS wie das Resilvering gehandhabt wird.
https://blogs.oracle.com/roch/entry/sequential_resilvering

Danke!

Die langsame Metadata-Durchguck-Phase kenn ich vom Scrub her, läuft das da ähnlich? Erst kommt man mit viel (hörbarem) Random-I/O kaum vorwärts, und dann läufts plötzlich sequentiell los. Und schon stehen ein paar 100 MB/s aufm Tacho.

Beim Resilver kann ich das nicht unbedingt sagen, ich hab halt wenig Änderung auf meinen ZFS, daher auch wenig Fragmentierung wegen CoW. Zumal der Füllstand nur 1/3 beträgt, also da niemand genötigt wird, irgendwelche kleinsten Lücken zu befüllen.

 

[trendco]

Noch mal bzgl. SSD-Pool:
GEA: Du hattest hier http://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-232.html#post23773319 mal die "Sandisk Extreme Pro" empfohlen.
Hast Du zufällig auch Erfahrung mit den "Samsung 850 Pro"?

In meinen Desktop PC's, iMac etc. hab ich bisher die "normalen" Samsung-EVO-840/850 verbaut und bin auch sehr zufrieden damit. Mir ist schon klar, dass die von den IO-Werten natürlich nicht an die Profi-SSD's (Intel etc.) ran kommen. Aber haben die auch noch andere Nachteile in Bezug auf den ZFS Einsatz? Oder könnt ich z.B. auch eine normale EVO-850 für mein Vorhaben nehmen?

 

[gea]

Noch mal bzgl. SSD-Pool:
GEA: Du hattest hier http://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-232.html#post23773319 mal die "Sandisk Extreme Pro" empfohlen.
Hast Du zufällig auch Erfahrung mit den "Samsung 850 Pro"?

In meinen Desktop PC's, iMac etc. hab ich bisher die "normalen" Samsung-EVO-840/850 verbaut und bin auch sehr zufrieden damit. Mir ist schon klar, dass die von den IO-Werten natürlich nicht an die Profi-SSD's (Intel etc.) ran kommen. Aber haben die auch noch andere Nachteile in Bezug auf den ZFS Einsatz? Oder könnt ich z.B. auch eine normale EVO-850 für mein Vorhaben nehmen?

Es ist alles im Fluss und wird konstant weiterentwickelt.
Für Storage statt Desktop use ist mir aber immer noch folgendes wichtig:
- Langlebigkeit und das ist eher MLC als TLC Nand
- Overprovisioning (also eher die serienmäßigen 480/960er MB als die 512/1024er SSD), klar kann man das per HBA nachholen.
damit konstant hohe Schreibraten auch unter Last
- lange Garantiezeit
- idealerweise Powerloss Save (das ist aber tatsächlich Pro)

Da fällt die Samsung Pro mit extra HBA drunter, nicht aber die Evo.

 

[Rahvin]

- idealerweise Powerloss Save (das ist aber tatsächlich Pro)

Welche Modelle gibt es die das tatsächlich können - auch für Nutzdaten und nicht nur für Verwaltungsdaten (außer Intel DC S3500 / S3700)?

 

[TCM]

Seit wann machen SSDs Unterscheidungen zwischen Meta-/Daten? Wenn das Ding einen Kondensator dafür hat, dann erwartet man, dass alle Blöcke ab dem Stromausfall auf der SSD landen.

 

[Rahvin]

Seit wann machen SSDs Unterscheidungen zwischen Meta-/Daten? Wenn das Ding einen Kondensator dafür hat, dann erwartet man, dass alle Blöcke ab dem Stromausfall auf der SSD landen.

Die Erwartung wird leider enttäuscht, daher die Frage nach konkreten Modellen welche tatsächlich sicher alle Daten die im Puffer gelandet sind auch auf Flash schreiben können.

Siehe bspw. diese Zusammenfassung: SSD stress testing finds Intel might be the only reliable drive manufacturer | ExtremeTech
Hersteller versprechen viel und verbauen vielleicht sogar einen kleinen Kondensator...

 

[gea]

Welche Modelle gibt es die das tatsächlich können (außer Intel DC S3500 / S3700)?

Die Samsung 845 DC Pro/ Evo soll das auch können.
Wenns aber wirklich darauf ankommt würde ich Intel DC 35xx, 36xx, 37xx oder HGST nehmen.
Für ein ZIL Device sogar die schnellsten wie die schreiboptimierten S3700.

 

[TCM]

Die Erwartung wird leider enttäuscht, daher die Frage nach konkreten Modellen welche tatsächlich sicher alle Daten die im Puffer gelandet sind auch auf Flash schreiben können.

Siehe bspw. diese Zusammenfassung: SSD stress testing finds Intel might be the only reliable drive manufacturer | ExtremeTech
Hersteller versprechen viel und verbauen vielleicht sogar einen kleinen Kondensator...

Erklärt immer noch nicht die angebliche Unterscheidung zwischen Nutz- und Metadaten, die die Frage als gegeben dargestellt hat. Woher kommt diese Info?

 

[trendco]

Ok, danke für die Info, d.h. im Schluss, keine speziellen Anforderungen in Bezug auf ZFS.

Bzgl. "Powerloss Save"
Was wär denn die schlimmste Folge von nem Powerloss bei ner SSD unter ZFS?
ZFS Dateisystem bleibt konsistent aber die letzten Sekunden vom aktuellen Schreibvorgang könnten fehlen?
Das wäre doch aber dann gleich wie wenn ne HD einen kleinen Cache hat, oder verstehe ich da jetzt was falsch?