Planung für ZFS Pool - 8 SSD´s + NVMEs

[lukesky85]

Hi,

ich habe mir kürzlich 8 4 TB SSD´s aus China bestellt und würde diese gerne in einen ZFS Pool betreiben.

außerdem habe ich noch 1x NVME 1 TB SSD und könnte mir gut vorstellen 2 x 480GB 2,5" Datacenter SSD´s (mit Strompuffer) noch dazu zu schalten als Cache mit Ausfallsicherheit durch die Kondensatoren.

- Die Daten auf den SSD´s sind nicht wichtig und könnten auch verloren gehen. Ich habe regelmäßige Backups auf alles was dort von Wert ist. Ich sehe wenig Grund für ein Mirror Setup mit mehreren VDEV´s
- Also wäre für mich eigentlich RAIDZ1 die richtige Wahl?
- Wenn ein Sektor auf einer SSD defekt ist, ist das für mich ja kein Beinbruch, ich habe ja z.B. erstmal 10% spare vom Speicherplatz.
- Resilvertime ist etwa ~20h. Die Schreibrate bricht nach 1TB stark ein auf 80-100MB/s statt 500MB/s
- Bringt es etwas, 2 480 GB Datacenter SSD´s dazu zu nehmen für die Kondensatoren?
- Es wird eh nur 1, maximal 2,5 GBit angeschlossen, ein hoher output ist also nicht unbedingt notwendig.

8x https://geizhals.de/4064132967
an HBA: https://geizhals.de/broadcom-sas-9207-8i-lsi00301-a800939.html

EEC RAM: 4x https://geizhals.de/micron-vlp-dimm-16gb-mta18adf2g72az-3g2r1r-a2802663.html
Datacenter SSDs: https://geizhals.de/kingston-dc450r-ssd-480gb-sedc450r-480g-a2163730.html gibs ab 30€ gebraucht.
MB: https://geizhals.de/asus-rog-strix-x570-e-gaming-90mb1150-m0eay0-a2079032.html

Vollständige Hardwareliste: https://geizhals.de/wishlists/3126720

 

[gea]

Hi,

ich habe mir kürzlich 8 4 TB SSD´s aus China bestellt und würde diese gerne in einen ZFS Pool betreiben.

außerdem habe ich noch 1x NVME 1 TB SSD und könnte mir gut vorstellen 2 x 480GB 2,5" Datacenter SSD´s (mit Strompuffer) noch dazu zu schalten als Cache mit Ausfallsicherheit durch die Kondensatoren.

ZFS nutzt ausschließlich RAM als Schreibcache. Eine L2Arc SSD als Lesecache braucht kein Mirror. Die dürfen kaputtgehen, dann nutzt ZFS halt nur RAM Lesecache. PLP brauchts bei L2Arc auch nicht. Ist nur wichtig für Slog oder SSD als Basic vdev ohne Raid.

- Die Daten auf den SSD´s sind nicht wichtig und könnten auch verloren gehen. Ich habe regelmäßige Backups auf alles was dort von Wert ist. Ich sehe wenig Grund für ein Mirror Setup mit mehreren VDEV´s
- Also wäre für mich eigentlich RAIDZ1 die richtige Wahl?

Bei SSD/NVMe Pools würde ich auch auf Raid Z[1-3] gehen und nicht auf Mirrors da iops bei SSD kein so großes Problem sind

- Wenn ein Sektor auf einer SSD defekt ist, ist das für mich ja kein Beinbruch, ich habe ja z.B. erstmal 10% spare vom Speicherplatz.

?

- Resilvertime ist etwa ~20h. Die Schreibrate bricht nach 1TB stark ein auf 80-100MB/s statt 500MB/s

Das ist normal bei günstigeren Desktop SSD. Gute Enterprise SSD machen das nicht so, manche wie Intel Optane haben gar keinen Einbruch.

- Bringt es etwas, 2 480 GB Datacenter SSD´s dazu zu nehmen für die Kondensatoren?

Nein zumindest nich als Lesecache.
Mit den SSD könnte man einen schnellen zweiten schnelleren Pool anlegen oder ein special vdev für small io und performancekritische Dateisysteme.

 

[ludwinator]

Oh je, soll soll man da anfangen?
Ordentliche DC SSDs für nen fuffy mehr, dafür den LSI günstig in der Bucht schießen (als HP oder sonstwas), IT Firmware drauf und gut.
Auch die beste Software kann schlechte Hardware nicht kompensieren.

 

[Trambahner]

Oh je, soll soll man da anfangen?

In der Tat.



"Günstigere Desktop SSD" ist sehr freundlich ausgedrückt. Meine Meinung dazu ist eher "*****" (selbst zensiert dass ich nicht gebannt werde).
Vor allem, wo es zum gleichen Preis 870 Evos in etwa auf diesem Preisniveau seit gewisser Zeit gibt dank dem Preisverfall. Das sind zwar auch Consumer-Drives, aber dort Premium im Sata-Bereich; mit ordentlich Dram-Cache, mit gutem TLC-Speicher und genug SLC-Cache. Plus Firmwaresupport und Herstellergarantie.
Solang es nicht Sync-Writes sind, wird die 870 Evo 4TB deuuutlich besser die Schreibraten halten als der o.g. noname-Kram, die Latzenzen blieben auch sehr niedrig (also das was man will).
Benchmark 870 4TB

Da klopp ich doch um Himmelswillen nicht dubiose Noname-SSDs aus nem Singlesource-Marketplace in den Rechner.

Warum fällt da jetzt schon TB-weise resilvern an???? Wenn das kein bewusster Test war, dann zeigt das nur, welcher xxxxx diese SSDs sind.

Warum so viel Geld einen alten SAS2308 Controller? Da würde ich mir auf der Bucht eher nen SAS3008 holen. Hat Ludwinator ja auch schon geschrieben.

Die DC450R scheint ok zu sein, wenn sie nicht kaputtgeschrieben sind. Die TBW sind für Datacenter sehr niedrig (das Ding ist i.W. auf Lesen ausgelegt, nicht permanent TB-weise Datenschreiben)

Der Ram ist ok, ich würde aber ohne Not keine 4 16er Module verbauen, sondern 2x32GB. Damit ist dann noch Reserve fürs Aufrüsten und falls man das nicht tut, wird der Ram-Controller der CPU weniger belastet. 4xDual Rank ECC mit 3200 MT/s kann bei manchen Ryzens schon problmetisch werden. Je nach Glück in der Silizum-Lotterie bei der CPU, das ist nämlich schon OC. (Meist gehts (bei mir geht auch 4x32 3200 ECC) aber manchmal halt nicht).
Ich hab in den beiden Servern auch Micron E-Die (Kingston-Module) bzw. nun auch Micron B-Die (Micron MTA18ASF4G72AZ-3G2R).

Ich frage aber auch mal: warum ECC-Ram, wenn auf der anderen Seite Noname-SSDs verwendet werden? Macht für mich keinen wirklichen Sinn.


Unter Strich:
Ich versteh das Zusammenstellungskonzept und die Entscheidungen für bestimmte Hardware dieser Maschine nicht. Was soll der Rechner sein ? Gaming? Filer? Server für Virtuelle Maschinen?
Ohne weitere Infos lässt mich das Setup etwas ratlos zurück...

 

[asche77]

Die Kingston DC450R haben aber keine Power loss protection. Also auch *****.

(Siehe https://www.kingston.com/de/ssd/dc450-data-center-solid-state-drive)

 

[ludwinator]

Aber immer noch viel besser als die China Kracher bei ähnlichem Preis!
SSD mit PLP, wie eine DC500R oder PM893 liegen eben 25% drüber.

 

[gea]

Das was eine SSD langlebig und auch schnell beim länger anhaltenden Schreiben macht bedeutet konstruktiven Aufwand und Know How. Qualität hat halt ihren Preis. Allerdings wird selbst eine einfache SSD beim wahlfreien Lesen und kurzfristigem Schreiben also in den meisten Fällen dennoch deutlich schneller als eine mechanische Platte sein. Mehr Sorgen würde mir Langlebigkeit machen. Dadurch dass bei SSDs weder einzelne Zellen noch Pages (ca 4-16kiB) beschrieben werden können sondern nur komplette Blocks die vor jeder Anderung gelöscht werden müssen (512KiB bis 2MiB) erzeugt eine SSD erheblich mehr Schreiblast als eine mechanische Platte. SSD sind also oft viel schneller abgenutzt als man gedacht hat. Mit einem extra 10% Overprovisioning z.B. per host protected area könnte man Langlebigkeit und Schreibperformance auf Kosten der Kapazität verbessern.

Fehlende SSD PLP ist genau wie fehlendes ECC eine der wenigen Risiken einer Datenkorruption die ZFS nicht konstruktiv beherrschen kann. Beide Risiken sind klein aber vorhanden. Im ZFS Raid können PLP Probleme vermutlich korrigiert werden. Bei single disk vdevs oder VM Storage Slog ist eine SSD ohne PLP fahrlässig. Bei einem ZFS Storageserver dem man Daten langfristig anvertraut mit der Hoffnung dass ZFS alle denkbaren Ursachen eines Datenverlusts bis auf Bugs und Hardwarefehler beherrscht ist beides mehr als ein nice to have.

Ist wie ESP beim Auto. Kostet, braucht man wahrscheinlich nie, sollte man aber trotzdem haben weil manchmal braucht man es halt doch ganz dringend.
vgl https://www.thomas-krenn.com/de/wiki/Solid-State_Drive

 

[lukesky85]

Wow Leute,
ganz schön viele Antworten zu Fragen die ich gar nicht gestellt habe. Danke, aber die Hardwareauswahl stand gar nicht wirklich zur Diskussion. Ich habe mich für die Auswahl entscheiden, da ich vorher Recherchiert habe und habe sie bewusst getroffen. Zumal ich eh nicht in einem Professionellen Umfeld unterwegs bin und Fehler bzw. Probleme mit der Hardware verkraften kann.

In der Tat.


[ungefragter Ratschlag]

Warum fällt da jetzt schon TB-weise resilvern an???? Wenn das kein bewusster Test war, dann zeigt das nur, welcher xxxxx diese SSDs sind.

Warum so viel Geld einen alten SAS2308 Controller? Da würde ich mir auf der Bucht eher nen SAS3008 holen. Hat Ludwinator ja auch schon geschrieben.

Die DC450R scheint ok zu sein, wenn sie nicht kaputtgeschrieben sind. Die TBW sind für Datacenter sehr niedrig (das Ding ist i.W. auf Lesen ausgelegt, nicht permanent TB-weise Datenschreiben)

Der Ram ist ok, ich würde aber ohne Not keine 4 16er Module verbauen, sondern 2x32GB. Damit ist dann noch Reserve fürs Aufrüsten und falls man das nicht tut, wird der Ram-Controller der CPU weniger belastet. 4xDual Rank ECC mit 3200 MT/s kann bei manchen Ryzens schon problmetisch werden. Je nach Glück in der Silizum-Lotterie bei der CPU, das ist nämlich schon OC. (Meist gehts (bei mir geht auch 4x32 3200 ECC) aber manchmal halt nicht).
Ich hab in den beiden Servern auch Micron E-Die (Kingston-Module) bzw. nun auch Micron B-Die (Micron MTA18ASF4G72AZ-3G2R).



Unter Strich:
[...]

Das resilvern wird, vorraussichtlich, länger dauern bei diesen SSD´s, weil sie auf 80-100mb runter gehen nach 1TB Schreiben. Überleg dir mal, wie du mit anderen Erwachsenen Menschen heir redest. Das ja hoch peinlich diese Art und weise mit seinen Quatsch Argumenten zu kommen.

Ich habe diesen SAS Controller gewählt, weil er absolut ausrechend für mich ist. Was soll ich mit einem SAS 3008?! Das Ding kostet neu 300€, das 10 x von dem was ich bezahlt habe.

Der Ram ist bereits gekauft. Danke für deinen Ratschlag. Wer bei EEC Server RAM auf OC achtet, hat eh irgendwas falsch verstanden. OC von Server Systemen oder Workstations ist nie empfehlenswert.

Danke für den Hinweis mit den DC450R, ich dachte die hätten 2 PB als TBW. Dann werden es wohl die Intel.

Unterm Strich
Du solltest wirklich an deiner Kommunikation arbeiten. Du hörst nicht zu und behauptest irgendwas ohne wirklich Erfahrung zu haben.

Das was eine SSD langlebig und auch schnell beim länger anhaltenden Schreiben macht bedeutet konstruktiven Aufwand und Know How. Qualität hat halt ihren Preis. Allerdings wird selbst eine einfache SSD beim wahlfreien Lesen und kurzfristigem Schreiben also in den meisten Fällen dennoch deutlich schneller als eine mechanische Platte sein. Mehr Sorgen würde mir Langlebigkeit machen. Dadurch dass bei SSDs weder einzelne Zellen noch Pages (ca 4-16kiB) beschrieben werden können sondern nur komplette Blocks die vor jeder Anderung gelöscht werden müssen (512KiB bis 2MiB) erzeugt eine SSD erheblich mehr Schreiblast als eine mechanische Platte. SSD sind also oft viel schneller abgenutzt als man gedacht hat. Mit einem extra 10% Overprovisioning z.B. per host protected area könnte man Langlebigkeit und Schreibperformance auf Kosten der Kapazität verbessern.

Fehlende SSD PLP ist genau wie fehlendes ECC eine der wenigen Risiken einer Datenkorruption die ZFS nicht konstruktiv beherrschen kann. Beide Risiken sind klein aber vorhanden. Im ZFS Raid können PLP Probleme vermutlich korrigiert werden. Bei single disk vdevs oder VM Storage Slog ist eine SSD ohne PLP fahrlässig. Bei einem ZFS Storageserver dem man Daten langfristig anvertraut mit der Hoffnung dass ZFS alle denkbaren Ursachen eines Datenverlusts bis auf Bugs und Hardwarefehler beherrscht ist beides mehr als ein nice to have.

Ist wie ESP beim Auto. Kostet, braucht man wahrscheinlich nie, sollte man aber trotzdem haben weil manchmal braucht man es halt doch ganz dringend.
vgl https://www.thomas-krenn.com/de/wiki/Solid-State_Drive

Ich denke, Consumer SSD´s sind zum absoluten Billigprodukt geworden, welches teuer an Kunden verkauft wird. Ich sehe keinen Grund die 80€ mehr hier zu zahlen.

1050€ +paar Euro ZOLL für 8 4TB SSD´s waren schon ein akzeptabler Preis. Die Alternative hätte mich etwa 1500€ gekostet in DE.

Ich denke ich werde auf ein kleines USV setzen und den Server direkt runterfahren lassen wenn der Stromausfällt. Das passiert hier 1x im Jahr und da kann ich dann auch auf den Server verzichten.

SSD´s halten länger als man denkt und wichtig ist ja erstmal wie das Persönliche Nutzungsmuster ist. Ich habe meist nur größere Schreiboperationen und alle VM´s/Docker Appdata´s sind auf einem anderen Laufwerk. Die neuen 4TB SSD´s sollen 2PB TBW haben lt. Hersteller. Damit werde ich ein paar Jahre hinkommen,

ZFS nutzt ausschließlich RAM als Schreibcache. Eine L2Arc SSD als Lesecache braucht kein Mirror. Die dürfen kaputtgehen, dann nutzt ZFS halt nur RAM Lesecache. PLP brauchts bei L2Arc auch nicht. Ist nur wichtig für Slog oder SSD als Basic vdev ohne Raid.


Bei SSD/NVMe Pools würde ich auch auf Raid Z[1-3] gehen und nicht auf Mirrors da iops bei SSD kein so großes Problem sind


?


Das ist normal bei günstigeren Desktop SSD. Gute Enterprise SSD machen das nicht so, manche wie Intel Optane haben gar keinen Einbruch.


Nein zumindest nich als Lesecache.
Mit den SSD könnte man einen schnellen zweiten schnelleren Pool anlegen oder ein special vdev für small io und performancekritische Dateisysteme.

Danke.
Ich muss nochmal schauen, es gibt doch meherere Arten von special devices und eins davon kann einen Schreibcache bereitstellen.

 

[asche77]

es gibt doch meherere Arten von special devices und eins davon kann einen Schreibcache bereitstellen.

Unfug.

 

[gea]

Ich muss nochmal schauen, es gibt doch meherere Arten von special devices und eins davon kann einen Schreibcache bereitstellen.

Nein.
Schreibcache ist bei ZFS immer und ausschließlich RAM. Ein Slog ist zwar auch ein spezielleres (kein special) vdev, ist aber kein Schreibcache sondern eine Absicherung des RAM Schreibcaches vor Datenverlust. Special Vdev ist für small io (meist Metadaten), Dedup und komplette Dateisysteme deren recsize kleiner ist als die small blocksize Einstellung des Dateisystem. Daten auf dem special vdev werden da auch nicht gecacht sondern die werden da gespeichert. Ist das special vdev defekt, ist damit auch der Pool verloren.

 

[ludwinator]

@lukesky85
Da frage ich mich natürlich, gab es denn eigentlich überhaupt eine Frage? Und wenn ja, wozu? Ich meine, du weisst ja eh alles und dozierst auch gleich noch über Inhalt und Kommunikationsstil, also wotsefak?
An alle anderen, die hier mitlesen und noch nicht so toll recherchiert haben: Was er hier schreibt ist quasi durch die Bank Unfug, bitte nicht nachmachen!

cu

 

[wddn]

Wenn die Daten nicht kritisch sind und du Backups hast:
8xSSD im RAIDZ1

SLOG und andere Cache Optionen kannst du dir sparen bei Max 2.5GBit

Gibt es eigentlich einen speziellen Grund warum es nicht 3, oder 4 HDDs geworden sind?
Ich habe 4x16TB im striped mirror (RAID10) und habe zwischen 300-500MB Übertragungsrate was eine 2.5Gbit NIC schon voll auslastet…

 

[Holt]

Dadurch dass bei SSDs weder einzelne Zellen noch Pages (ca 4-16kiB) beschrieben werden können sondern nur komplette Blocks die vor jeder Anderung gelöscht werden müssen

Das ist nicht richtig! NAND wird sowohl pageweise gelesen und als auch beschrieben, aber eben nur blockweise gelöscht.

 

[lukesky85]

Wenn die Daten nicht kritisch sind und du Backups hast:
8xSSD im RAIDZ1

SLOG und andere Cache Optionen kannst du dir sparen bei Max 2.5GBit

Gibt es eigentlich einen speziellen Grund warum es nicht 3, oder 4 HDDs geworden sind?
Ich habe 4x16TB im striped mirror (RAID10) und habe zwischen 300-500MB Übertragungsrate was eine 2.5Gbit NIC schon voll auslastet…

Weil ich keine Festplatten nutzen möchte. Sie sind mir zu laut.
Für Massenspeicher habe ich 120 TB in der cloud liegen.

Beitrag automatisch zusammengeführt: 07.07.2023

Nein.
Schreibcache ist bei ZFS immer und ausschließlich RAM. Ein Slog ist zwar auch ein spezielleres (kein special) vdev, ist aber kein Schreibcache sondern eine Absicherung des RAM Schreibcaches vor Datenverlust. Special Vdev ist für small io (meist Metadaten), Dedup und komplette Dateisysteme deren recsize kleiner ist als die small blocksize Einstellung des Dateisystem. Daten auf dem special vdev werden da auch nicht gecacht sondern die werden da gespeichert. Ist das special vdev defekt, ist damit auch der Pool verloren.

Danke für die Infos. Ich denke ich verzichte auf Special devs und nutze lieber die unraid Cache Funktionalität für Ordner wo es nützlich ist.

 

[gea]

Das ist nicht richtig! NAND wird sowohl pageweise gelesen und als auch beschrieben, aber eben nur blockweise gelöscht.

Es geht um Änderungen oder um Schreiben in einen teilweise belegten Block. Dann muss der komplette Block gelöscht werden. Schreiben einer Page in einen freien Bereich nach Trim oder Garbage Collection oder bei einer leeren SSD ist was anderes,

siehe Schreibzugriffe in https://www.thomas-krenn.com/de/wiki/Solid-State_Drive
Damit Sie einzelne Pages innerhalb eines Blocks beschreiben können, muss der gesamte Block zuvor gelöscht werden. Bei einer fabrikneuen SSD sind alle Blöcke gelöscht. Es steht somit ausreichend Platz zum direkten Schreiben zur Verfügung. Bei steigendem Füllstand der SSD kann es passieren, dass der SSD Controller zuerst einen ganzen Block von bis zu 2MB lesen muss, obwohl vielleicht nur wenige Bytes davon geändert werden (Read-Modify-Write).

 

[lukesky85]

@lukesky85
Da frage ich mich natürlich, gab es denn eigentlich überhaupt eine Frage? Und wenn ja, wozu? Ich meine, du weisst ja eh alles und dozierst auch gleich noch über Inhalt und Kommunikationsstil, also wotsefak?
An alle anderen, die hier mitlesen und noch nicht so toll recherchiert haben: Was er hier schreibt ist quasi durch die Bank Unfug, bitte nicht nachmachen!

cu

es gab doch einige die mich verstanden haben und super nützliche infos gegeben haben. Icj denke die nächsten Fragen stelle ich lieber wieder auf englischsprachigen subreddits. Die dt. Community ist leider wie wir hier sehen etwas strange.

Gerade deine Antwort oben zeugt doch nur von nachplappern von dem was du irgendwo aufgeschnappt hast. hast du diese Hardware irgendwann mal getestet? Hast du Erfahrungen mit Full ssd raids? Hast du Erfahrung mit diesen ssds? Hast du Erfahrung mit dem Controller den du empfohlen hast? Mir ging es vor allem um Erfahrungswerte und nicht um die Dinge die ich ohnehin schon kannte.

Beitrag automatisch zusammengeführt: 07.07.2023

Es geht um Änderungen oder um Schreiben in einen teilweise belegten Block. Dann muss der komplette Block gelöscht werden. Schreiben einer Page in einen freien Bereich nach Trim oder Garbage Collection oder bei einer leeren SSD ist was anderes,

siehe Schreibzugriffe in https://www.thomas-krenn.com/de/wiki/Solid-State_Drive
Damit Sie einzelne Pages innerhalb eines Blocks beschreiben können, muss der gesamte Block zuvor gelöscht werden. Bei einer fabrikneuen SSD sind alle Blöcke gelöscht. Es steht somit ausreichend Platz zum direkten Schreiben zur Verfügung. Bei steigendem Füllstand der SSD kann es passieren, dass der SSD Controller zuerst einen ganzen Block von bis zu 2MB lesen muss, obwohl vielleicht nur wenige Bytes davon geändert werden (Read-Modify-Write).

Ich denke letzteres sieht man dann in HTOP als IOWAIT.

 

[gea]

Weil ich keine Festplatten nutzen möchte. Sie sind mir zu laut.
Für Massenspeicher habe ich 120 TB in der cloud liegen.

Beitrag automatisch zusammengeführt: 07.07.2023

Danke für die Infos. Ich denke ich verzichte auf Special devs und nutze lieber die unraid Cache Funktionalität für Ordner wo es nützlich ist.

Der rambasierte ZFS Schreib/Lesecache ist immer aktiv und so effizient dass er die prinzipbedingten ZFS Performancenachteile (mehr Daten wegen Prüfsummen, mehr Fragmentierung wegen Copy on Write) mehr als ausgleicht. Diesen ZFS Cache über einen weiteren Cache zu überlagern ist kontraproduktiv und führt eher zu einer geringeren Over All Performance. Man könnte bei sehr vielen kleinen volatilen Daten allenfalls einen L2Arc Lesecache hinzufügen um mehr Metadaten zu cachen. Der ist persistent (übersteht reboot) und kann auch optional read ahead. Das kann bei sequentiellen Daten und Plattenpools die Performance verbessern. Bei SSD/NVMe Pools hilft eh nur Arc Ramcache, alles andere bringt nichts.

 

[Trambahner]

Hast du Erfahrungen mit Full ssd raids?

Ja. mehrere SSD-only ZFS-Pools verschiedener Typen. Über mehrere Jahre hinweg, mehrere aktuell in Betrieb. Von guten Consumer-SSDs bis Datacenter. Aktuell z.B. eben mit 870 Evo und SN850 für den kleinen Server und PM9A3 7.68TB SSDs für den großen. SM863 und SM883 hatte ich auch schon (die liegen grad rum). Aktuelle Systeme stehen in meiner Signatur.

Hast du Erfahrung mit diesen ssds?

Kingspec? Nein, denn ich kaufe grundsätzlich nur SSDs namhafter Hersteller mit bekannten Controllern, Flash-Bestückung und vollständigen Datenblättern. Insbesondere, wenn viel Geld reingehen soll.

Hast du Erfahrung mit dem Controller den du empfohlen hast?

Ja. Ich habe HBAs mit SAS2008, SAS2308, SAS3008 und SAS3416. Alle im ZFS-Einsatz seit 2013 gehabt bzw. stehen teilw. im Einsatz. Mit HDD-Pools und SSD-Pools.

Hoffe, das waren jetzt keine "ungefragten Quatsch-Ratschläge", nachdem Du ja originär nicht mich gefragt hast.

 

[Holt]

Es geht um Änderungen oder um Schreiben in einen teilweise belegten Block. Dann muss der komplette Block gelöscht werden. Schreiben einer Page in einen freien Bereich nach Trim oder Garbage Collection oder bei einer leeren SSD ist was anderes,

SSDs haben immer mehr NAND Kapazität verbaut als nutzbar ist und werden kaum einen ganzen Block löschen müssen um eine Page darin zu überschreiben, sondern normalerweise den neuen Inhalt der Page auf eine freie Page in einem anderen Block schreiben und deren Adresse in der Mappingtabelle eintragen. Sind dann zu viele Pages mit ungültigen Daten in einem Block, werden irgendwann bei der Idle-GC die noch gültigen Daten in dem Block umkopiert und der Block wird gelöscht.

Thomas Krenn irrt da also, offenbar wurde vergessen das jede SSD eine Free Area hat und die ist auch bei Consumer SSD i.d.R. mindestens 7% groß, bei Enterprise SSDs teils noch deutlich größer. eben um genau dies zu vermeiden. Wird eine SSD vollgeschrieben und dann mit zufälligen 4k Schreibzugriffen überschrieben, also im Steady State betrieben, was allenfalls bei Enterprise SSDs je der Fall sein wird, dann muss der Controller noch während des Schreibvorgangs den Vorgang die gültigen Daten in einem Block zu kopieren um diesen Block zu löschen durchführen und deshalb fällen dann die IOPS Schreibend auch massiv ab, je nach SSD mehr oder wenig deutlich und bei Consumer SSDs meist weit stärker als bei Enterprise SSDs und für Enterprise SSD ist dies dann auch die Angabe die man als IOPS Schreibend im Datenblatt finden wird, weshalb die so viel geringer ausfallen als bei Consumer SSDs.

Trotzdem bleibt diese Aussage falsch:

Dadurch dass bei SSDs weder einzelne Zellen noch Pages (ca 4-16kiB) beschrieben werden können sondern nur komplette Blocks die vor jeder Anderung gelöscht werden müssen (512KiB bis 2MiB)

NAND wird Pageweise gelesen und beschrieben, klar es können nur leere Page beschrieben werden und Blockweise gelöscht. Es ist aber eben nicht so, dass ein Controller bei jeder Änderung einer Page immer einen ganzen Block löschen muss, dies könnte vielleicht im unglücklisten Fall mal passieren, aber dürfte im Alltag nie vorkommen.

 

[gea]

Es ist aber eben nicht so, dass ein Controller bei jeder Änderung einer Page immer einen ganzen Block löschen muss

Das hat auch niemand behauptet.

, dies könnte vielleicht im unglücklisten Fall mal passieren, aber dürfte im Alltag nie vorkommen.

Trim und Garbage Collection sollen Read-Modify-Write kompletter Blöcke verhindern indem immer freie bereitstehen. Klappt auch ganz gut im Desktop und einer nicht zu vollen SSD der die größte Zeit im Idle verbringt. Bei SSD die eine hohe Dauer Schreiblast haben (Severbetrieb), etwas voller sind oder etwas verbrauchter/älter wird Read-Modify-Write eines Blocks schon häufiger vorkommen. SSD optimieren um immer genügend freie Blöcke über Trim oder Garbage Collection bereitzustellen kostet ja auch dann Performance wenn Read-Modify-Write im Hintergrund passiert. Sieht man ja auch an den Eiinbrüchen bei SSD steady write oder mixed read/write. Egal warum, SSD haben hier ein strukturelles Manko bei hoher Last, Desktop SSD mehr, Datacenter SSD weniger, Optane keins.

 

[Holt]

Trim und Garbage Collection sollen Read-Modify-Write kompletter Blöcke verhindern indem immer freie bereitstehen.

Das verhindert vor allem die Free Area, also vor allem die Tatsache das SSDs eben mehr NAND als Nutzkapazität haben. TRIM sagt dem Controller nur, dass die Daten die der getrimmten Adresse zugeordnet waren, nun ungültig sind und gelöscht werden können, was dann irgendwann mal passiert, man möchte ja nicht einen ganzen Block der viele Hundert bis einige Tausend Pages umfasst umkopieren und löschen müssen, nur weil die Daten einer Page ungültig geowrden sind. Das man die getrimmten Daten trotzdem schon nach einigen Sekunden nicht mehr lesen kann, liegt einfach daran das der LBA aus der Mappingtabelle entfernt wird und wenn der dann gelesen wird, liefert der Controller einfach Nullen zurück.

Bei SSD die eine hohe Dauer Schreiblast haben (Severbetrieb), etwas voller sind oder etwas verbrauchter/älter wird Read-Modify-Write eines Blocks schon häufiger vorkommen.

Keine Ahnung was das mit dem Alter zu tun haben soll, aber SSDs für schreibintensive Anwendungen haben noch mehr Free Area (manchmal auch als Overprovisioning bezeichnet) um eben Read-Modify-Write zu vermeiden und wenn dann doch einer nötig ist, dann zu vermeiden das man dabei so viele Pages mit noch gültigten Daten hat die man kopieren muss, dass der frisch gelöschte Block in den man sie kopiert schon wieder fast voll ist.

Sieht man ja auch an den Eiinbrüchen bei SSD steady write oder mixed read/write.

Bei den Einbrüchen im Steady State bei Writes ja, die Einbrüche bei Mixed I/O kommen aber eher daher, dass die NAND Dies dann entweder für Lesen oder Schreiben adressiert werden müssen und man muss halt warten bis da eine fertig ist, bevor das andere begonnen werden kann. Ich weiß nicht ob es noch ist, aber ich meine früher war pro Kanal nur eine Richtung möglich und wenn dann 4 oder gar 8 Dies an dem Kanal hängen und von einem gelesen wird, müssen alle Schreibzugriffe warten bis der Lesevorgang beendet ist, während es durchaus möglich "gleichzeitig" (in Anführungsstrichen, denn es kann immer nur mit einem Die am Kanal zur Zeit kommuniziert werden, aber wähend man z.B. beim Lesen nach der Anfrage auf die Daten wartet, kann man im Interleaveverfahren ein anderes Die ansprechen und dort auch Daten adressieren oder die vorher angeforderte Daten empfangen) Daten von den Dies an einem Kanal zu lesen oder zu schreiben. Deshalb haben Enterprise SSD Controller ja meist auch mehr NAND Channels als Consumer SSD Controller, weil dies das Problem der Einbrüche bei gleichzeitigen Lese- und Schreibvorgängen minimiert.

Optane keins.

Die haben eine ganz andere Technik und 3D X-Point mit wahlfreiem Zugriff wie RAM statt NAND Flash. Optane sind eine feine Technik, waren aber leider zu teuer um am Markt gegen die meistens ausreichend guten, aber viel billigeren SSDs mit NAND Flash zu überleben.

 

[lukesky85]

Hi,

falls sich jemand für die Performance Interessiert und hier durch Google draufkommt:
Bis 1 / 3 der Festplattengröße (also ca bei 1,3 TB), bricht die Schreibleistung von 550mb/s auf 100mb/s ein.
Sie haben 4,1TB statt 4,0TB.
Lt. Hersteller sind 2PB TBW "garantiert"

 

[ludwinator]

an dieser Stelle wiederhole ich mich gerne: Bitte nicht nachmachen!