SSD Volume mit/ohne SSD Cache


nicx

Recommended Posts

Hallo @mgutt, Hallo Allerseits.

 

On 6/2/2021 at 12:07 PM, mgutt said:

Er will ja Docker/VM drauf laufen lassen. Daher nutzt er sie auf jeden Fall. Alleine der Parity-Rebuild / Check geht mindestens doppelt so schnell.

Wenn ich hier einhaken und fragen darf:

Mein Testarray besteht aktuell aus vielen 8TB HDD mit SMR (bisher zum Befüllen ohne Parity. Die erzeuge ich später.). Durch die Schreiblastverteilung der Shares geht das kosntant erstaunlich Flott.

Da die Schreiblast bei Parity sehr hoch ist, habe ich dafür zur Zeit 2 Stück 8TB Platten ohne SMR (1*Ironwolf und einmal Exos) bereit liegen, die ich dann später hinzufügen udn dann erst Parity erstellen lassen will.

Aber ich frage mich ob da eine oder 2  8TB SSD (selbst Samsung SSD 870 QVO 8TB SATA MZ-77Q8T0BW sollten ausserhalb des SLC Cache die Festplatten problemlos in den Schatten stellen) an der Stelle nicht vielleicht besser sein müssten.

Ich las daß die Schreiblast die SSD zu schnell verschleißen würden.

Andererseits las ich, dass es schon Leute mit nur SSD unraid Erfahrung haben. Kann man abschätzen ob SSD als Parity wirklich eher weniger zu empfehlen sind oder macht es doch etwas Sinn?

Ich weiß, eine eher schwammige Frage auf die es keine perfekte/handfeste Antwort gibt, deshalb bitte ich um subjektive Einschaetzungen.

:)

 

Link to comment
5 minutes ago, DataCollector said:

Andererseits las ich, dass es schon Leute mit nur SSD unraid Erfahrung haben. Kann man abschätzen ob SSD als Parity wirklich eher weniger zu empfehlen sind oder macht es doch etwas Sinn?

Ich weiß nicht wie du dein Array benutzt, aber meins ist eher ein Cold Storage. Soll heißen wenn meine 126TB voll sind, dann sind sie voll und werden kaum noch überschrieben. Wir sprechen hier also von einer TBW von sagen wir mal 300, die über die gesamte Lebenszeit eine SSD aushalten können muss. Die SSD 870 QVO 8TB hat eine TBW von 2.880. Also 10x mehr. Da wird es also niemals dran scheitern. Allerdings hat sie nur einen festen SLC Cache von 6GB, denn wenn man sie als Parity einsetzt, wird sie zu 100% vollgeschrieben und der dynamische SLC Cache fällt auf 0 (eigentlich 72GB). Sobald du also mehr als 6GB aufs Array schreibst, fällt die Schreibrate auf 160 MB/s, was weniger ist als bei einer schnellen HDD. 

 

Also das geht schon mit einer SSD, aber bitte nicht mit der QVO. Die ist einfach Müll. Doof ist jetzt, dass man sonst keine SSD mit 8TB findet. Alle anderen haben nämlich 7,68TB. Apropos. Denk dran, dass wenn die QVO nur 1 Bit kleiner ist als die größte HDD, dann kann man sie gar nicht als Parity einsetzen. Das kommt ja immer wieder mal vor. Da ist Vorsicht geboten.

 

Ich denke wir müssen auf die 880 QVO warten und hoffen, dass sie noch ein bisschen bei der Schreibleistung zulegt.

Link to comment

Hallo @nicx

 

Nur eine klitzekleien Anmerkung:

On 6/8/2021 at 7:59 AM, nicx said:

* Austausch des SATA-Controllers auf einen ASMedia ASM1166

 

Achtung: Den Chip gibt es auf PCIe 3.0 x1 Karten und auf Karten mit PCIe 3.0 x2 (Bauform mechanisch meist x4, aber eben nur x2 elektzrisch beschaltet).

Auch der ASM1166 kann nicht zaubern und bringt auf den x1-Karten nur in Summe knapp unter 1GByte/s und ist somit fuer die maximal vorgesehenen 6 SATA Ports etwas langsam angebunden um alle Ports mit SSD gleichzeitig voll auszufahren.

Solltest Du also mehr als 2-3 SATA Ports mit SSD belegen wollen beachte,d ass Du einen Kontroller mit mehr als nur x1 nimmst und Dein Board dazu passend auch PCIe 3.0 oder besser in dem Slot nutzt.

Zur Zeit sind diese Karten uebrigens anscheinend rar und teuer (ich schaetze mal auch daran ist Chia mit Schuld).

 

Link to comment

Hallo @mgutt.

 

Quote

Ich weiß nicht wie du dein Array benutzt, aber meins ist eher ein Cold Storage.

An der Stelle, an die ich hierbei denke, ist es primaer nur ein Lager. Backups, eine Sammlung an Software, die ich immer mal brauche und auffrische um ohne Internetverbindung auch Systeme frisch aufsetzen zu koennen, Images, Videos, Audiobooks, Musik und so weiter. Also nach Erstbefüllung nichts mit hoher Veränderung, sondern meist nur kleinere Datenmengen. Bei Aufnahmen (meist SD) von VU+ Receivern würde ich das Array gerne als Speicherplatz nutzen (als Ersatz für mein aktuelles 4HDD NAS) und einmal pro Woche lese ich die DVB-C SD Dateien aus, beschneide sie und das Ergebnis kommt zurück auf das Array.

 

Quote

Die SSD 870 QVO 8TB hat eine TBW von 2.880. Also 10x mehr. Da wird es also niemals dran scheitern. Allerdings hat sie nur einen festen SLC Cache von 6GB, denn wenn man sie als Parity einsetzt, wird sie zu 100% vollgeschrieben und der dynamische SLC Cache fällt auf 0 (eigentlich 72GB). Sobald du also mehr als 6GB aufs Array schreibst, fällt die Schreibrate auf 160 MB/s, was weniger ist als bei einer schnellen HDD. 

Naja, eien schnelle HDD erreicht die Rate auch nur, wenn sie halbwegs wenig befüllt ist, die vorliegenden 8TB HDDs (Ironwulf und Exos) schaffen in Spitze Sequentiell auch nur so um die 180MByte/s (HDTunePro Write) und bei SSD hoffe ich wegen der wegfallenden Rotation auf eine merklich höhere Performance.

Ohne den SLC Cache ist zumindest bei der 4TB Vorgaengern sogar nur 150MByt/s drin. Aber wie schon gesagt, gegenueber der SMR Platten oder den vorhandenen 8TB Ironwulf und Exos sollten die SSD dennoch sehr bemerkbar sein.  So hoffe ich zumindest.

Ich ueberlege zusätzlich, ob ich wirklich 8TB SSD nehme oder je 2 Stück 4TB per Hardwarerraid0 zusammenschalte um damit mehr Performance zu erreichen.

Aber das wäre dann wieder eine weitere Baustelle. Tueer wuerde es sowieso bei der Kapazitaet. :D

Schön wäre, wenn man die Parität aus vielen kleinen SSD zusammensetzen könnte (8*1 TB SSD = 1x8TB Paritaet). Aber das hat unraid wohl nicht drauf.

 

 

Quote

Also das geht schon mit einer SSD, aber bitte nicht mit der QVO. Die ist einfach Müll.

..aber preiswert.

Ich habe 4TB Vorgaenger und 2TB Seriengleichen davon und sie sind erwartungsgemaess gut. Natürlich nichts, was eine 'normale SSD' schafft, aber bei dem Einsatz in dem ansonsten SMR HDD Array ist eine 'normale SSD' noch teurer und bringt mir vermutlich keinen weiteren Vorteil.

 

Quote

Doof ist jetzt, dass man sonst keine SSD mit 8TB findet.

Alternativ (oben erwähnt) einfach 2 Stück 4TB als Hardwarerraid0/BigDisk zusammen schalten. Erhöhtes Ausfallrisiko, aber dafür hat man ja Parität (und zusätzlich natürlich ein bisher unerwähntes Backup). Es gibt ja so schön niedliche 3,5Inch Gehäuse mit Einbaumöglichkeit für 2Stück 2,5Inch Laufwerk und verbautem Raidkontroller).

 

Quote

Alle anderen haben nämlich 7,68TB.

Okay, ich hoffe unraid würde es auch akzeptieren, wenn ich je eine 7,xx TB als Parität einbaue und die restlichen Platten des Array dann eben nur mit 7,xx TB benutzt werden, selbst wenn es 8TB Platten sind. In dem vorgesehenen Einsatzszenario wäre die Differenz durch hinzustecken einer weiteren Festplatte verschmerzbar.

 

 

Quote

Apropos. Denk dran, dass wenn die QVO nur 1 Bit kleiner ist als die größte HDD, dann kann man sie gar nicht als Parity einsetzen. Das kommt ja immer wieder mal vor. Da ist Vorsicht geboten.

Bei nomalen Raidkontrollern wird dann eben die geringere Kapazitaet auf allen Datentraegern genutzt (natürlich muß man dann das Array doch mit den neuen Werten neu einstellen. Kann unraid das nicht? Ich habe es so noch nicht mit unraid ausprobiert.

 

Edited by DataCollector
Adressat nachgetragen
Link to comment
10 minutes ago, DataCollector said:

Okay, ich hoffe unraid würde es auch akzeptieren, wenn ich je eine 7,xx TB als Parität einbaue und die restlichen Platten des Array dann eben nur mit 7,xx TB benutzt werden

Leider nein.

 

11 minutes ago, DataCollector said:

Es gibt ja so schön niedliche 3,5Inch Gehäuse mit Einbaumöglichkeit für 2Stück 2,5Inch Laufwerk und verbautem Raidkontroller).

Haben die denn genug Performance für 2 SSDs? Also schaffen die SATA voll auszulasten? Ich habe von diesen Adaptern in Sachen Stabilität auch immer nur Schlechtes gelesen. Dass so eine Broadcom Karte deutlich teurer ist, hat denke ich schon seinen Grund.

 

Ansonsten wäre so ein Adapter natürlich super um die Schreibrate im RAID0 zu verdoppeln.

Link to comment

Hallo @mgutt

 

55 minutes ago, mgutt said:

Leider nein.

 

Oh! Das überrascht mich nun. Dann also wirklich mindestens 8TB Datenträger für Parität.

Schade, da hatte ich in meine rbewunderung für unraid wohl zuviel erhofft.

Danke!

 

55 minutes ago, mgutt said:

Haben die denn genug Performance für 2 SSDs?

Ich hatte mal in meienr Anfangszeit von SSD (2013) ein solches Gehäuse IB-RD2121StS ( https://www.raidsonic.de/products/internal_cases/soho_raid/index_de.php?we_objectID=933 ) mit einem verbauten JMB390 gekauft. Nein, dieser alte JMB ist dafür nicht performant genug.

Aber solche Gehäuse haben sich weiter entwickelt und beinhalten nun laut Spezifikation leistungsfähigere Bridges.

Auf meiner kuerzlich durchgeführten Suche nach Raid0/BigDisk-Bridges für 3,5Inch Festplatten bin ich auf viele solcher Gehäuse für 2,5Inch Datenträger von diversen Herstellern gestoßen.

Praktische Erfahrungen habe ich aber mit den neueren Varianten noch nicht. Teilweise sind aber die verbauten Chips erwaehnt und die klingen zumindest fuer die gebuendelte Performance von Samsungs QVO ausreichend.

 

55 minutes ago, mgutt said:

Also schaffen die SATA voll auszulasten?

Die Gehäuse, welche ich kürzlich sah, wurden als SATA 6G beschrieben und auch die technischen Spezifikationen der teilweise zu findenden Chiphersteller klangen so.

Natürlich können die nicht mehr als SATA6G nach aussen liefern und somit reicht es, wenn die 2 SSD je nur die Hälfte liefern oder sich ergänzen.

Wie meinem vorherigen Beitrag zu entnehmen ist: Mir geht es dabei nicht um das letzte bisschen Leistung, aber dennoch um weitaus bessere Performance als eine 7200RPM HDD.

 

55 minutes ago, mgutt said:

Ich habe von diesen Adaptern in Sachen Stabilität auch immer nur Schlechtes gelesen.

Der damalige JMB390 war im Betrieb stabil. Das Gehäuse habe ich sogar vor einigen Wochen wieder gefunden, weshalb ich auch wieder auf die Idee mit dem Hardwareraid gekommen bin um unraid mehr Kapazität vorzugaukeln, als der jeweilige echte Datenträger hat.

Aber ich habe das Gehäuse damals dennoch nicht lange eingesetzt.

 

55 minutes ago, mgutt said:

Dass so eine Broadcom Karte deutlich teurer ist, hat denke ich schon seinen Grund.

Diese Karten koenne ja auch viel mehr.

Und nein, einfache Broadcom Karten, die auch nur Raid0 und 1 und eine sehr begrenzte Anzahl von Datenträgern betreiben können sind nicht mehr wirklich viel teurer.

 

55 minutes ago, mgutt said:

Ansonsten wäre so ein Adapter natürlich super um die Schreibrate im RAID0 zu verdoppeln.

man erkauft es sich nur eben damit, dass die Wahrscheinlichkeit eines Ausfalles größer wird. Aber das ist bei raid0 so. Wobei man evtl. auch BigDisk nutzen kann, dann hat man bei den Dingern zumindets eien bessere Datenrettungschance, wenn einer der Datenträger verstirbt.

Link to comment
17 minutes ago, DataCollector said:

Ich hatte mal in meienr Anfangszeit von SSD (2013) ein solches Gehäuse IB-RD2121StS ( https://www.raidsonic.de/products/internal_cases/soho_raid/index_de.php?we_objectID=933 ) mit einem verbauten JMB390 gekauft. Nein, dieser alte JMB ist dafür nicht performant genug.

Bei solchen Gehäusen wäre ich vorsichtig. 

Die sind komplett geschlossen und demnach wird es ziemlich warm darin. Das geht auf dauert auf die Haltbarkeit der Platten.

Lieber etwas offenes suchen wo auch ein ordentlicher Luftzug über die Platten geht.

Link to comment

Hallo @i-B4se

 

1 hour ago, i-B4se said:

Die sind komplett geschlossen und demnach wird es ziemlich warm darin.

Da darin nur SATA Laufwerke laufen, diese auch nicht beide gleichzeitig voll ausgefahren werden können, ist das wenigere in problem. Die SSD selber sind ja schon in dem 2,5Inch Gehäuse eingesperrt. Die Wärmeabfuhr bei solchen SATA SSD ist da weniger ein Problem.

NVMe SSD hingegen sind aufgrund der erheblich höheren Leistung und kleineren Bauform dahingehend ein Problem.

 

 

1 hour ago, i-B4se said:

Das geht auf dauert auf die Haltbarkeit der Platten.

Die SSD in diesen 2,5Inch Gehäusen sind auch relativ dicht abgeschlossen.

 

1 hour ago, i-B4se said:

Lieber etwas offenes suchen wo auch ein ordentlicher Luftzug über die Platten geht.

Wenn Du eine geeignete Alternative nennst, die den Anforderunegn entspricht, wäre es interessant zu erfahren.

 

Wie gesagt, das von mir verlinkte Gehäuse ist eine Variante von 2013. Da war die Temperatur sowieso noch kein Problem. Die neueren gehäuse, die ich gefunden hatte hatten teilweise Luftschlitze oder Metallelemente.

Link to comment

In normalen PC Betrieb sicher richtig, aber bei einem Paritycheck oder wenn gerade ordentlich geschrieben wird, werden die Platten schon warm,

Mir ist vorgestern ein Festplattenlüfter vom Backup-Unraid ausgefallen und die Platten wurden gerade beschrieben. Hab dann meine Mails kontrolliert und festgestellt das die Platten gerade 62°C haben.

AUch SSDs können ordentlich warm werden, vor allem wenn sie wie ein Sandwich übereinander liegen. 

 

Wichtig ist dann ein konstanter Luftzug, vor allem bei so einem geschlossenen Gehäuse bei denen es keine Kühler gibt.

 

Leider kann ich dir keine alternative sagen, da ich solche Systeme bisher nicht benötigt habe. Ich will die auch nicht schlecht reden, aber im Serverbereich sollte schon alles gut belüftet werden. 

Link to comment

Hallo @i-B4se

 

6 hours ago, i-B4se said:

In normalen PC Betrieb sicher richtig, aber bei einem Paritycheck oder wenn gerade ordentlich geschrieben wird, werden die Platten schon warm,

Mir ist vorgestern ein Festplattenlüfter vom Backup-Unraid ausgefallen und die Platten wurden gerade beschrieben. Hab dann meine Mails kontrolliert und festgestellt das die Platten gerade 62°C haben.

Daß Festplatten sehr warm werden ist klar. Wenn ich meine 4HE anwerfe klingen die wegen der Lüfter eher wie Staubsauger.

Als ich unterschiedliche Lüfter getestet habe sind temperaturen >60Grad bei 24 Festplatten under Last keine Seltenheit gewesen.

Aber bei SATA SSDs sieht es da nicht ganz so schlimm aus.

Natürlich werden sie unter Last auch wärmer.

Natürlich wirkt sich eien belastung außerhalb der Spezifikation (zu warm) auf die Lebensdauer aus.

Aber zwei heutige 7mm hohe 2,5Inch SSD haben in einem 3,5Inch Gehäaeuse viel Luft drum herum und diese 3,5Inch gehäuse sind ja auch nicht hermetisch abgeschlossen.

 

 

6 hours ago, i-B4se said:

AUch SSDs können ordentlich warm werden, vor allem wenn sie wie ein Sandwich übereinander liegen. 

Wenn sie zu eng liegen ja, aber das ist ja nicht der Fall.

Ich betreibe 8 SATA SSD (6 davon zu je 2TB zu einem Laufwerk zusammengefasst) in einem Fantec MR-SA1082 SLIM.

Das bedeutet, daß die 6 SSD alle immer gleichzeitig angesprochen werden und teilweise schuften die über Stunden hinweg.

Keine hat bisher auffällige Temperaturprobleme gezeigt.

Und ja, dort ist ein winziger Lüfter angebracht, der aber leider nicht wirklich viel Luft bewegt.

 

6 hours ago, i-B4se said:

Wichtig ist dann ein konstanter Luftzug, vor allem bei so einem geschlossenen Gehäuse bei denen es keine Kühler gibt.

 

Bei Festplatten ja.

Bei SATA SSD in der 2,5Inch Bauform ist die SSD Platine in dem 2,5Inch Gehäuse vom Luftzug sowieso abgeschnitten. Die Gehäuse sind auch meist nur punktuell als Kühlkörper verbunden. (IronWolf 110 480GB):

Fireblsblog_IMG_20190406_185252-1024x768

 

Die 2,5Inch SATA SSD 'brät' also sowieso in ihrem 'Gehäuseaquarium'.

Schönes Bild einer 850 Evo 250GB im Netz:

samsung-850-evo-2-test-03-jpg.678993

oder hier auch ein bisschen Video https://www.pcgameshardware.de/SSD-Hardware-255552/Videos/Samsung-SSD-850-Evo-vorgestellt-1145133/

 

Ja, luftdicht abschließen würde ich 2,5inch SATA SSD auch nicht und ja, selbst die winzige Luftbewegung des Miniquirls ist sinnvoll.

Aber SATA SSD in dieser Bauform sind schon in ihren Gehäusen nicht so eng ge- und verbaut und deshalb nicht so hitzköpfig und empfindlich, wie es bei NVME SSD zu sehen ist.

 

 

6 hours ago, i-B4se said:

Leider kann ich dir keine alternative sagen, da ich solche Systeme bisher nicht benötigt habe. Ich will die auch nicht schlecht reden, aber im Serverbereich sollte schon alles gut belüftet werden. 

Grundlegend stimme ich Dir vollkommen zu und betreibe auch meien SSD nicht ohne gute Luftbewegung und die NVMe auch mit extra Kühlkörper.

Aber in dem von mir mal gekauften udn auch den vor kurzem recherchierten 3,5Inch Doppelgehäusen sehe ich dahingehend nur ein geringes Problem, da diese die Situation der Kühlung nicht nennenswert verschärfen.

So zumindest meine Erfahung und Einschätzung.

Natürlich ist das nicht bezogen auf absolute professionelles highperformance Equipment. Die Gehäuse richten sich ja auch nicht an Profis. Profis kaufen gleich etwas ganz

anderes.

Ich bin eben nur das, was man als ambitioniertern Nutzer bezeichnen kann.

Link to comment
10 hours ago, DataCollector said:

Oh! Das überrascht mich nun. Dann also wirklich mindestens 8TB Datenträger für Parität.

Schade, da hatte ich in meine rbewunderung für unraid wohl zuviel erhofft.

 

Das hat nix mit Unraid zu tun sondern liegt in der Natur der Paritätsberechnung. Für jede Bit-Position der Datenplatten muss es eine identische Bit-Position auf den Parity-Platten geben.

 

Wenn auf einer Datenplatte Bit-Position 7.999.999.999.999 existiert und die Paritätsplatte bei 7.999.999.999.998 endet, wo soll denn dann die Parität für das überschüssige Bit geschrieben werden?

 

Das geht technisch nicht anders. Deshalb müssen Paritätsplatten mindestens so gross sein wie die größte Datenplatte im Array.

 

Link to comment

Hallo @hawihoney

 

6 hours ago, hawihoney said:

Das hat nix mit Unraid zu tun sondern liegt in der Natur der Paritätsberechnung. Für jede Bit-Position der Datenplatten muss es eine identische Bit-Position auf den Parity-Platten geben.

...sofern man eben die Datenplatten voll nutzen will.

Mir ist bewußt, das dies hier rein theoretisch ist, weil man hiervon die Leute von Lime überzeugen müßte.

Dennoch:

Doch warum sollte es nicht möglich sein die 8TB Datenplatten vom Anfang nur bis zu einem bestimmten Level zu nutzen (beispielsweise 7TB (wird durch Shares 'Minimun free sapce' ja sowieso gebrenzt), so daß die Paritätsplatten auch nur 7TB groß sein müssen?

Das würde dann sogar die Weiterbenutzung von stabilen laufenden Festplatten mit einzelnen defekten Sektoren ermöglichen, indem man das Array von vorne herein nicht maximal aufbaut.

Bei SSD gibt es da den Begriff Overprovisioning und auch Festplatten können in bestimmten Mengen Sektoren auslagern,

Es wäre also nur eine Frage der Software eben nicht 100% jedes Datenträgers zu nutzen.

Denn 100% jedes Datenträgers wird ja in der Regel sowieso nie ausgenutzt, wenn man 'minimum free space' nutzt um beim Aufschreiben keine großen Dateien in Fehler laufen zu lassen.

 

6 hours ago, hawihoney said:

Wenn auf einer Datenplatte Bit-Position 7.999.999.999.999 existiert und die Paritätsplatte bei 7.999.999.999.998 endet, wo soll denn dann die Parität für das überschüssige Bit geschrieben werden?

Solange dieses Bit nie benuutzt wird, ist es egal. Und nur, weil es das ....9te Bit auf der Datenplatte gibt, muß dieses Bit nicht im Array verwendung finden.

Aber wie gesagt, das ist eben die Ueberlegung, die man bei Raid ja auch hat. Man orientiert sich bei der Erstellung an dem kleinsten Datentraeger oder entsprechend eingestelltem Wert. Der Rest wird ignoriert.

 

 

6 hours ago, hawihoney said:

Das geht technisch nicht anders. Deshalb müssen Paritätsplatten mindestens so gross sein wie die größte Datenplatte im Array.

 

Das liegt dann eben an der Software fuer diese Art Array. Wenn die Software einstellbar nur 50 aller Datenplatten nutzt und den Rest ignoriert, braucht auch die Paritaetsplatte nur so viel Platz besitzen.

 

Link to comment
2 hours ago, DataCollector said:

Doch warum sollte es nicht möglich sein die 8TB Datenplatten vom Anfang nur bis zu einem bestimmten Level zu nutzen (beispielsweise 7TB (wird durch Shares 'Minimun free sapce' ja sowieso gebrenzt), so daß die Paritätsplatten auch nur 7TB groß sein müssen?

Reicht das doch mal als Verbesserungsvorschlag ein:

https://forums.unraid.net/forum/53-feature-requests/

Link to comment
2 hours ago, DataCollector said:

Aber wie gesagt, das ist eben die Ueberlegung, die man bei Raid ja auch hat.

 

Man sagt zwar immer Unraid sei kein RAID, es ist aber quasi RAID-4 im Array:

 

https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_4

 

Deine Überlegung ist also z.B.: Ich nutze 2x 4 TB als Parity-Platten und 2x 8 TB als Datenplatten, da ich weiß, dass ich nur 4 TB Platz für Daten pro Datenplatte benötige. Wenn ich dann mehr Platz auf den Datenplatten benötige, schraube ich 2x Parity-Platten mit mindestens 8 TB ein?

 

Ist doch das gleiche, nur andersherum, oder?

 

Gelebt und dokumentiert ist: Man nimmt immer die größte(n) Platte(n) als Parity - steht überall in den Handbüchern. Bei Dual-Parity kannst Du sogar eine kleinere Parity-Platte nutzen - also z.B. 1x 8 TB und 1x 4 TB. Das würde ja schon fast Deiner Vorstellung entsprechen ;-)

 

https://wiki.unraid.net/Manual/Storage_Management#Parity_Disks

 

Link to comment
On 6/14/2021 at 8:19 AM, nicx said:

Eine Frage noch, zwar eher nicht direkt zum Thema passend, aber zumindest ein wenig "speicher-relevant": Ist es empfehlenswert alle Docker-Mounts für Persistance Data grundsätzlich direkt nach appdata zu mounten oder eventuell auf einen eigenen Share? Mir gehts vor allem um die Userdaten hier, und das Handling dieser beim Backup/Restore, vor allem bei "grösseren" Containern wie Mailserver und Nextcloud.

 

Konkretes Beispiel: Ich habe einen Mailserver-Docker installiert und frage mich ob ich die User Maildirs auf /mnt/appdata/mailserver-docker/maildata belasse oder auf einen eigenen Share z.b. /mnt/user/mail lege?!

 

habt ihr aus Profi-Sicht hier zu meiner Frage noch eine Einschätzung eurerseits? :)

Link to comment
On 6/14/2021 at 8:19 AM, nicx said:

Eine Frage noch, zwar eher nicht direkt zum Thema passend, aber zumindest ein wenig "speicher-relevant": Ist es empfehlenswert alle Docker-Mounts für Persistance Data grundsätzlich direkt nach appdata zu mounten oder eventuell auf einen eigenen Share? Mir gehts vor allem um die Userdaten hier, und das Handling dieser beim Backup/Restore, vor allem bei "grösseren" Containern wie Mailserver und Nextcloud.

 

Kommt darauf an. Zu einem kompletten Backup eines Containers gehören m.E. sowohl die Container config als auch die Container data. Bei sehr vielen kleineren Containern verbirgt sich beides in config. Nehmen wir als Beispiel Nextcloud. Dort hast Du MariaDB config - was nach meinem Verständnis data enthält - und Nextcloud mit separatem data und config.

 

Bei einer sehr großen Installation würde ich speicher-technisch MariaDB von Nextcloud trennen und bei Nextcloud zusätzlich eine Trennung von config und data vornehmen - obwohl bei der Nextcloud config eher weniger los ist. Bei großen Installationen würde ich darüber einfach nicht nachdenken und es direkt so machen.

 

Im kleineren Rahmen - zumal mit NVMe M.2 wie bei mir - kann alles auf einem Storage liegen. Ich habe MariaDB und Nextcloud komplett auf einem Storage liegen. Allerdings sieht es bei mir anders aus als von Unraid vorgesehen - ist halt historisch gewachsen:

 

/mnt/pool/system/appdata/mariadb/

/mnt/pool/system/appdata/nextcloud.config/

/mnt/pool/system/appdata/nextcloud.data/

 

Und gesichert wird ohnehin bei gestoppten Containern, dann kannst Du gleich alles sichern:

 

docker stop nextcloud

docker stop mariadb

... alles sichern

docker start mariadb

docker start nextcloud

 

Edited by hawihoney
Link to comment

Danke fürs Feedback. In meinem Fall nutze ich nextcloud sowieso nur mit external directories, d.h. ich habe meine Userdaten auf extra Shares. MariaDB habe ich wie du in einem extra Container laufen.

 

Im Grunde würde ich es dann so handhaben:

* Alle Daten die für den Betrieb des Services/Containers selbst notwendig sind (z.b. configs) liegen direkt beim Container unter appdata

* Alle reinen Userdaten (Dokumente, Medien, Software und eben auch die Maildirs für den Mailserver) würde ich auf jeweils eigene Shares im Array legen und in den Container mounten.

 

Edited by nicx
Link to comment
  • 3 weeks later...

Nachdem nun mein Testserver einige Wochen im Betrieb ist habe ich übers Wochenende die Live-Migration durchgeführt.

Bzgl. der SATA Performance kann (bzw. muss) ich erst einmal mit dem Einsatz des besagten Marvell-SATA-Controllers leben (der bestellte ASMedia ASM1166 Ersatzcontroller aus China kam leider nicht an, wurde beim Zoll festgesetzt :(

 

root@nas:/mnt/user/appdata/nginx/www# ./diskspeed.sh
diskspeed.sh for UNRAID, version 2.6.5
By John Bartlett. Support board @ limetech: http://goo.gl/ysJeYV
Warning: Files in the array are open. Please refer to /tmp/lsof.txt for a list
/dev/sdb: 545 MB/sec avg
/dev/sdc: 554 MB/sec avg
/dev/sdd: 469 MB/sec avg
/dev/sde: 428 MB/sec avg
/dev/sdf: 428 MB/sec avg
/dev/sdg: 119 MB/sec avg

 

1524736085_Bildschirmfoto2021-07-05um09_24_35.png.55fed82fca885ad8dc47d3036852b287.png

 

Die Einzelplatten performen sehr gut (/dev/sdg ist eine klassische 5400er HDD), das Array hingegen hat Luft nach oben:

 

root@nas:/mnt/user/appdata/nginx/www# dd if=/dev/zero of=/mnt/user/test.img bs=1G count=5 oflag=dsync
5+0 records in
5+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 123.461 s, 43.5 MB/s
root@nas:/mnt/user/appdata/nginx/www# dd if=/dev/zero of=/mnt/user/test.img bs=1G count=5 oflag=dsync
5+0 records in
5+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 78.4803 s, 68.4 MB/s
root@nas:/mnt/user/appdata/nginx/www#

 

566999919_Bildschirmfoto2021-07-05um09_39_49.thumb.png.22f8e469c03150a6bee0d91769569a69.png

 

Ist das nun genau dem SATA-Controller geschuldet? Oder gibt es noch andere Ansätze?

 

Link to comment
54 minutes ago, nicx said:

dsync

Die Option solltest du denke ich nicht setzen. Du umgehst damit denke ich das Buffering von Linux und schreibst kleinste Chunks direkt. Ich teste so:

dd if=/dev/zero of=/mnt/... bs=128K iflag=count_bytes count=10G

 

Außerdem nicht /mnt/user sondern /mnt/disk1, sonst limitiert die CPU durch den Unraid Overhead (SHFS).

Link to comment

@mgutt guter Hinweis, danke dir! Hier die Performance Ergebnisse:

 

root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G
81920+0 records in
81920+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 55.902 s, 192 MB/s
root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G
81920+0 records in
81920+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 81.8906 s, 131 MB/s
root@nas:~#
root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G
81920+0 records in
81920+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 51.3179 s, 209 MB/s
root@nas:~# 

 

Immerhin, ich denke aber trotzdem dass der SATA Controller hier einiges an Performance bringt, korrekt?

Link to comment

Mich verwundern diese extremen Schwankungen. Wobei 250GB EVO... Kann es sein, dass deren SLC Cache ziemlich klein ist? Bedenke, dass Schreibvorgänge mit vollem SLC Cache deutlich langsamer sind. Also besser eine große Pause dazwischen lassen und die Datei ruhig mal löschen, statt sie zu überscheiben. Bedenke auch, dass im Array kein Trim möglich ist. Du musst also auf die Firmware warten, dass die Irgendwann die Garbage Collection ausführt.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.