Frage zur Nutzung von Unraid als VM Server

[mgutt]

35 minutes ago, Smolo said:

Aber klar als Vergleichsmessung

Darum geht es.

 

36 minutes ago, Smolo said:

Bezüglich den 15w guck dir mal diesen Test Renoir Desktop hier an.

Anandtech misst nur die 12V der CPU.

 

40 minutes ago, Smolo said:

Was bringt es mir wenn das System ohne Ausstattung 6w zieht und ich dann GPU, Netzwerk, SATA, M.2 nachrüsten muss denn dann komme ich wieder auf ähnlich Werte.

Mein System zieht mit 8 schlafenden HDDs, 10G Karte, M.2 NVMe und 64GB ECC RAM 20W. 6W fallen dabei alleine auf die 10G Karte. Mittlerweile sind es 10 HDDs, ich musste deswegen eine SATA Karte nachrüsten und ich musste den SATA Port Standby opfern, weil die Karte sonst abschmiert. 28W.

 

 

[Smolo]

15 minutes ago, mgutt said:

Darum geht es.

 

Anandtech misst nur die 12V der CPU.

 

 

 

 

Bin da jetzt nicht in der Materie was das für Auswirkungen hat aber warum verbraucht dann die gleiche CPU weniger beim X570 als beim B550?

 

 

Quote

Mein System zieht mit 8 schlafenden HDDs, 10G Karte, M.2 NVMe und 64GB ECC RAM 20W. 6W fallen dabei alleine auf die 10G Karte. Mittlerweile sind es 10 HDDs, ich musste deswegen eine SATA Karte nachrüsten und ich musste den SATA Port Standby opfern, weil die Karte sonst abschmiert. 28W.

 

Naja nehme ich den Gedanken ganz noch mal auf und schiele bei ASRock Rack auf den alten x470 mit 10GB (X470D4U2-2T). Problem kein Support für Renoir / Vermeer zur Zeit.

Was hast du für Mobo, das aus der Empfehlung ganz am Anfang?
Was nutzt du für NIC?

[mgutt]

4 hours ago, Smolo said:

das x570 zieht in dem Test 5w weniger wie die gleiche Hardware mit B550 Mainboard

Das X570D4U auf Platz 1 ist "Ohne dGPU" also ohne Grafikkarte. Wie man sieht macht die 13W aus, da das X570D4U auch mit Grafikkarte gelistet ist. Also nix sparsamer als B550.

[mgutt]

3 hours ago, Smolo said:

warum verbraucht dann die gleiche CPU weniger beim X570 als beim B550?

Bei Anandtech? Wo?

 

3 hours ago, Smolo said:

Was hast du für Mobo, das aus der Empfehlung ganz am Anfang?
Was nutzt du für NIC?

Ich habe das Mini ITX C246N-WU2 wegen Platzmangel. Empfehlen kann ich dir das C246M-WU4 (teuer geworden) oder W480M Vision W (erfordert Unraid Beta/RC), denn die haben 2x M.2 (meins nicht). 

 

War noch nie verfügbar:

https://www.asrockrack.com/general/productdetail.asp?Model=W480M WS#Specifications

 

Für 10G nutze ich die Karte von Qnap (RJ45, Aquantia).

[Smolo]

16 minutes ago, mgutt said:

Das X570D4U auf Platz 1 ist "Ohne dGPU" also ohne Grafikkarte. Wie man sieht macht die 13W aus, da das X570D4U auch mit Grafikkarte gelistet ist. Also nix sparsamer als B550.

Immer gut wenn zwei drüber schauen damit hast du natürlich recht.

 

Dennoch selbst wenn wir vom sparsamsten B550 13w abziehen dann landen wir bei 33,5w vs. 39w und jetzt noch den ASpeed AST2500 (BMC) einpreisen und die zusätzlichen Komponenten! Das TUF Gaming wäre nach dem Test dann aber auch bei 37w wenn wir die dediezi1rte Graka abziehen.

[mgutt]

Jo. Das ist halt kein 5000er Ryzen. Und nicht alle B550 Boards sind besonders sparsam. Ich weiß nur, dass Asus Boards nach entsprechender Einstellung im BIOS die PCIe Steckplätze auf L1 (Standby) stellen kann. Siehe auch:

https://www.computerbase.de/forum/threads/renoir-und-b550-die-idle-kuenstler.1967755/

 

Nützt dir aber eh nichts. B550 hat einfach zu wenig Lanes.

[Smolo]

11 hours ago, mgutt said:

Mein System zieht mit 8 schlafenden HDDs, 10G Karte, M.2 NVMe und 64GB ECC RAM 20W. 6W fallen dabei alleine auf die 10G Karte. Mittlerweile sind es 10 HDDs, ich musste deswegen eine SATA Karte nachrüsten und ich musste den SATA Port Standby opfern, weil die Karte sonst abschmiert. 28W.

 

Hierzu noch eine kleine Unraid spezifische Fragestellung. Wenn du von 8/10 schlafenden Festplatten sprichst trifft dies in der Realität überhaupt auf?

 

Klassisches NAS, Raid5 und größer, läuft alles auch wenn ich eine Cache SSD davor knalle sofern da auch nur irgendwas auf das Raid permanent drauf  lesen/schreiben muss

 

Unraid > Cache Array > HDD Array

 

Szenario 1: 24x7 Services nur auf Cache - ist das bei dir so umgesetzt? Wie gehst du hier mit dem Backup / permanent Speicherung um?

Szenario 2: 24x7 Services auf Cache mit Speicherung auf HDD Array  bedeutet die Parity Disc und die eine Platte mit dem Inhalt laufen permanent, die anderen können in den Spindown?

Szenario 3: 24x7 Services direkt auf zusätzliche Platte/n im Spiegel laufen lassen > Sicherungsszenario wie bei Szenario 1 zu realisieren?

 

Supportet Unraid outofthebox die Integration eines Raid 1? (sorry für die Frage hab gestern Nacht das erste mal in Unraid live reingeschaut und nicht so richtig die Struktur verstanden)

       

 

[saber1]

Dir scheint das Prinzip von unRaid noch nicht ganz klar zu sein.

 

Schau Dir diesen Beitrag einmal an. Eventuell wird es dann klarer: https://www.kodinerds.net/index.php/Thread/60933-How-To-unRAID-und-die-Verwendung-von-Cache-Drives/

 

Die HDD's (inkl. Parity) laufen nur, wenn drauf geschrieben wird.

Nach welcher Zeitspanne sie in den Spindown gehen sollen, kannst Du einstellen.

[Smolo]

On 1/21/2021 at 9:49 AM, saber1 said:

Dir scheint das Prinzip von unRaid noch nicht ganz klar zu sein.

 

Schau Dir diesen Beitrag einmal an. Eventuell wird es dann klarer: https://www.kodinerds.net/index.php/Thread/60933-How-To-unRAID-und-die-Verwendung-von-Cache-Drives/

 

Die HDD's (inkl. Parity) laufen nur, wenn drauf geschrieben wird.

Nach welcher Zeitspanne sie in den Spindown gehen sollen, kannst Du einstellen.

Ja es ist immer schwer sowas theoretisch zu diskutieren. Ich habe aktuell mal meinen urlten Server (AMD 605e / 8GB)  mit 128gb SSD und ein paar alten HDDs hergerichtet, um einfach mal die Funktion von Unraid zu testen. Das System läuft auf jeden Fall um Welten besser als mein QNAP Nas mit Atom  Quadcore (J1900 mit 16GB).

 

Was mir dabei aufgefallen ist das 2 meiner Platten keinen Spin Down machen trotz 15min Timer und auch nicht wenn ich es manuell anstoße. Woran könnte das liegen?

 

Das Verwalten vom Cache / Mover / Prefer im Zusammenspiel mit VMs/Container will mir allerdings noch nicht richtig in den Kopf rein. Aktuell habe ich es zum Test mal wie folgt konfiguriert.

 

Ich möchte ja die Daten speziell von den Appdate / Domains so sicher wie möglich haben. Mit dem Prefer Modus ist es mir total unklar wie ich, da ein Backup durchführe wenn die Daten jetzt verteilt auf dem Array oder dem Cache liegt oder schiebt Unraid dann alle Daten des Shares komplett auf die Cache Platten?

 

Die Option Yes würde ja bedeuten ich muss die Daten der VMs / Container dann per Scheduler oder manuell Moven. Wie schaut es in dem Fall mit der Konsistenz der VM / Container Daten aus? Bedeutet der Move das er den kompletten Datenstand vom Cache auf das Array zieht?

 

PS: Ist es Normal das beim Anlegen eines Shares laufende Kopiervorgänge abgebrochen bzw. angehalten werden?

Edited January 24, 2021 by Smolo

[mgutt]

6 hours ago, Smolo said:

Was mir dabei aufgefallen ist das 2 meiner Platten keinen Spin Down machen trotz 15min Timer

Ich tippe darauf, dass hier ein Container / VM Daten auf den HDDs liegen hat. Bei Shares rechts auf View und die "Location" prüfen. Steht da nur Cache oder auch eine Disk?

 

6 hours ago, Smolo said:

oder schiebt Unraid dann alle Daten des Shares komplett auf die Cache Platten?

Ja, aber nur, wenn sie nicht benutzt werden. Man sollte also kurz den Docker und VM Dienst vollständig abschalten, den Mover starten und dann bleiben sie bei Prefer auch auf der SSD.

 

6 hours ago, Smolo said:

unklar wie ich, da ein Backup durchführe

 

Es gibt diese Laufwerks-Pfade:

/mnt/cache/sharename = SSD

/mnt/disk1/sharename

/mnt/disk2/sharename

 

Und diesen Share-Pfad, der die Summe der oben genannten ist:

/mnt/user/sharename

 

Sicherst du also letzteren, sicherst du alle Daten von sharename, egal auf welchem Laufwerk sie gerade liegen (wobei er die SSD nicht einschließen würde, wenn man den Cache von sharename auf "No" stellt).

 

6 hours ago, Smolo said:

Appdate / Domains so sicher wie möglich

Dann sollte man ein SSD RAID1 konfigurieren. Also zwei SSDs. Zusätzliche Backups sowieso.

 

6 hours ago, Smolo said:

Ist es Normal das beim Anlegen eines Shares laufende Kopiervorgänge abgebrochen bzw. angehalten werden?

Ja leider. Das wurde schon häufiger bemängelt. Unraid startet dann den SMB Dienst komplett neu.

 

6 hours ago, Smolo said:

Die Option Yes würde ja bedeuten ich muss die Daten der VMs / Container dann per Scheduler oder manuell Moven

Nein. Yes bedeutet, dass sie temporär auf der SSD liegen und dann vom Mover auf die HDDs verschoben werden.

 

Ich nutze Yes für alle Nutzershares, No für Backup-Shares und Prefer für VMs, Docker und meine MP3 Sammlung (damit die HDDs nicht ständig angehen, wenn einer Musik hören will). Only finde ich sinnfrei.

 

6 hours ago, Smolo said:

Bedeutet der Move das er den kompletten Datenstand vom Cache auf das Array zieht?

 

Ja. So als würdest du eine Datei von einer Platte zur anderen verschieben. Mehr macht der Mover nicht.

 

 

[Smolo]

13 hours ago, mgutt said:

Ich tippe darauf, dass hier ein Container / VM Daten auf den HDDs liegen hat. Bei Shares rechts auf View und die "Location" prüfen. Steht da nur Cache oder auch eine Disk?

 

Gestern Abend mal ein Neustart und das Thema hat sich erledigt gehabt eventuell hat er hier was verschoben beim Anfahren weil ich das Array auch kurz gestoppt hatte.

 

Quote

Ja, aber nur, wenn sie nicht benutzt werden. Man sollte also kurz den Docker und VM Dienst vollständig abschalten, den Mover starten und dann bleiben sie bei Prefer auch auf der SSD.

 

 

Es gibt diese Laufwerks-Pfade:

/mnt/cache/sharename = SSD

/mnt/disk1/sharename

/mnt/disk2/sharename

 

Und diesen Share-Pfad, der die Summe der oben genannten ist:

/mnt/user/sharename

 

Sicherst du also letzteren, sicherst du alle Daten von sharename, egal auf welchem Laufwerk sie gerade liegen (wobei er die SSD nicht einschließen würde, wenn man den Cache von sharename auf "No" stellt).

Kurze Nachfrage zur Sicherheit. Wenn ich das System auf "No" Stelle dürften auf der Cache Disk ja auch keinerlei Daten liegen von diesem Share?

 

Quote

Nein. Yes bedeutet, dass sie temporär auf der SSD liegen und dann vom Mover auf die HDDs verschoben werden.

 

Ich nutze Yes für alle Nutzershares, No für Backup-Shares und Prefer für VMs, Docker und meine MP3 Sammlung (damit die HDDs nicht ständig angehen, wenn einer Musik hören will). Only finde ich sinnfrei.

Hm die Anmerkung zum Only Stand ja so auch in dem verlinkten Thread am Anfang. Allerdings geht es mir ehr bei dem Prefer so als beim Only. Dazu ein kleines Beispiel Szenario:

 

Beispiel:

1tb Cache Drive und 3TB Fotodaten die immer schnell im Zugriff sein sollten (Ordner durchscrollen mit 800 Bildern) und die Bilder werden an diversen Screens als Bildschirmschoner bzw. Hintergrund angezeigt.

 

Beim Prefer ist folgendes vermerkt:

If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array.
When the mover is invoked, files and subdirectories are transferred off the array and onto the Cache disk/pool

 

Was ist das Ergebnis?

- Nach der Beschreibung würde Prefer dafür sorgen das alle Fotodaten vom HDD Array auf das NAS Array übertragen werden?

- Das würde natürlich nicht funktionieren da wir ja nur 1tb Cache Drive haben. Was passiert jetzt also?

- Wie funktioniert der Toogle zwischen zu wenig Speicherplatz und dem Holen/Ablegen der Daten auf dem Cache Drive?

- Wo kann ich eine Maximalgrenze des Cache eines Shares einstellen?

- Ansonsten habe ich ja das Problem das mir Prefer meine Platte Cache Platte dicht macht auf der auch meine VMs liegen?

- Wenn ich Domains / die VMs auf Preferred Stelle zieht Unraid die IMGs Files auf den Cache aber da kommen die doch nie wieder runter? Dann kann ich doch gleich sagen Only?

 

[Smolo]

Anbei noch eine Frage zu einem kleinen Gedankenspiel (Foto Server und permanenter Random Zugriff):

Wenn ich Daten sicher ablegen möchte aber trotzdem jeder Zeit schnell darauf lesend zugreifen möchte, ohne das die Platten alle anfahren, wäre es doch möglich 1-2 Platten im Array als SSDs auszulegen?

 

D.h.:

- Cache = YES oder No (je nach wieviel Performance man beim initialen Schreiben benötigt)

- Share "Fotos" nur diesen speziellen Platten zuweisen

 

Ergebnis

- Der lesende Zugriff geht an der Parity Platte vorbei und sollte dann doch mit voller Bus Bandbreite oder entsprechend geringer Latzenz erfolgen können?

 

Hintergrund:

- Die Crucial P2 2TB NVME Platten gibt es aktuell für ca. 150€. Wenn ich mit einem Bifurcation Adapter arbeite könnte ich mir bis zu vier von den Platten ins NAS donnern und hätte einen sehr stromsparenden und extrem schnellen Lesezugriff?

[mgutt]

1 hour ago, Smolo said:

Wenn ich das System auf "No" Stelle dürften auf der Cache Disk ja auch keinerlei Daten liegen von diesem Share

Außer du hattest den Share vorher mit Cache im Einsatz. Dann bleiben die Dateien auf dem Cache, denn No heißt, dass auch der Mover nicht mehr auf dem Cache nachschaut. Falls also vorher Yes oder Prefer eingestellt war, erst abwarten bis der Mover den Share vom Cache entfernt hat.

 

1 hour ago, Smolo said:

- Nach der Beschreibung würde Prefer dafür sorgen das alle Fotodaten vom HDD Array auf das NAS Array übertragen werden?

- Das würde natürlich nicht funktionieren da wir ja nur 1tb Cache Drive haben. Was passiert jetzt also?

Der Cache läuft komplett voll. Will man nur bestimmte Fotos auf dem Cache haben zb nur die vom aktuellen Jahr, muss man also einen separaten Share dafür nutzen.

 

Es gibt noch einen Trick, den ich später für ein "Hot Cache" Plugin nutzen möchte. Und zwar werde ich die Last Access Time überwachen und alle sehr heißen Dateien bis x GB Gesamtgröße auf die HDD kopieren. Der Mover kann keine Dateien verschieben, die auch auf der HDD liegen. So bleiben die heißen Dateien ständig auf der SSD. Ich denke dieses Feature fehlt Unraid noch.

 

1 hour ago, Smolo said:

Wo kann ich eine Maximalgrenze des Cache eines Shares einstellen?

Das ist nicht möglich. Daher auch die Idee mit dem Plugin.

 

1 hour ago, Smolo said:

Dann kann ich doch gleich sagen Only?

Ja, außer du kopierst mal eine VM, weil du sie noch mal starten willst und zu dem Zeitpunkt ist dann der Cache voll. Mit Prefer ist es einfach ein No-Brainer.

 

1 hour ago, Smolo said:

Der lesende Zugriff geht an der Parity Platte vorbei und sollte dann doch mit voller Bus Bandbreite oder entsprechend geringer Latzenz erfolgen können?

Der lesende Zugriff geht immer an der Parity vorbei. Die Parity läuft ausschließlich bei Writes. Aber ja, du kannst auch SSDs ins Array packen. Die Latenz ist natürlich deutlich geringer.

 

1 hour ago, Smolo said:

Wenn ich mit einem Bifurcation Adapter arbeite könnte ich mir bis zu vier von den Platten ins NAS donnern und hätte einen sehr stromsparenden und extrem schnellen Lesezugriff?

Tja, das kommt darauf an ob die Standby Funktion über Bifurcation ordentlich funktioniert. Aber ich denke mal schon. Sollte ja alles nativ sein.

 

Ich habe ja mal überlegt ein SSD Only NAs zu bauen. Eine 8TB Micron ION 5210 als Parity und sonst nur 2 und 4TB SSDs im Array. Da man eine Parity nicht trimmen kann, wäre meine Hoffnung, dass die restlichen 4TB ausreichen um langfristig kein Performance-Problem zu bekommen. Oder man nimmt zwei ION und schmeißt alle 4 Wochen eine raus und lässt sie rebuilden, falls es doch Probleme dadurch gibt.

[Smolo]

1 hour ago, mgutt said:

Der Cache läuft komplett voll. Will man nur bestimmte Fotos auf dem Cache haben zb nur die vom aktuellen Jahr, muss man also einen separaten Share dafür nutzen.

Gibt es irgendwo eine Doku wie der Prefer im Detail funktioniert? Also zieht er jetzt alles aus dem Share per Definition rüber oder nur das was im Zugriff ist? Ersteres wäre ja ein schlimmer Fail wenn man die Cache Obergrenze pro Share nicht setzen kann weil ich dann ja per Definition einen Cache mit 100% hätte?! 😐

 

Quote

Es gibt noch einen Trick, den ich später für ein "Hot Cache" Plugin nutzen möchte. Und zwar werde ich die Last Access Time überwachen und alle sehr heißen Dateien bis x GB Gesamtgröße auf die HDD kopieren. Der Mover kann keine Dateien verschieben, die auch auf der HDD liegen. So bleiben die heißen Dateien ständig auf der SSD. Ich denke dieses Feature fehlt Unraid noch.

 

Ja das denke ich auch eine solche Bastellösung ist aber glaube ich der verkehrte Weg das kann dir ja mit jedem Update um die Ohren fliegen. Eigentlich sollte das Prefer ehr wie ein Festplatten Cache funktionieren bzw. wie bei den anderen Lösungen bei QNAP etc.. Pro Share müsste man die Größe definieren können und dann soll er da solange in beide Richtungen die Daten ablegen/rausnehmen wie sie im Zugriff sind.

 

Quote

Das ist nicht möglich. Daher auch die Idee mit dem Plugin.

 

Ist dein Cache dann immer voll oder wie muss ich mir das vorstellen? Eigentlich würde ich 500GB gerne für die VM + Docker reservieren das klappt aber nur für die VM wenn ich ihr gleich eine entsprechend große Partition zuweise. Bei den Dockercontainer kann ich ja kein Limit setzen oder habe ich da was übersehen?

 

Wo für ist dann in dem Rahmen das Setting "minimum free space" beim Share?

Wie geh ich dann mit den Warnmeldungen bezüglich vollem Cache um wenn der immer Volllaufen muss? *binverwirrt*

 

Quote

Der lesende Zugriff geht immer an der Parity vorbei. Die Parity läuft ausschließlich bei Writes. Aber ja, du kannst auch SSDs ins Array packen. Die Latenz ist natürlich deutlich geringer.

 

 

Mir geht es da erstmal drum das keine Platten laufen und die Zugriffslatenz entsprechend gering ist. Wenn das durchgegeben wird sollte das doch ordentlich performen 🙂

Quote

Tja, das kommt darauf an ob die Standby Funktion über Bifurcation ordentlich funktioniert. Aber ich denke mal schon. Sollte ja alles nativ sein.

 

Ich habe ja mal überlegt ein SSD Only NAs zu bauen. Eine 8TB Micron ION 5210 als Parity und sonst nur 2 und 4TB SSDs im Array. Da man eine Parity nicht trimmen kann, wäre meine Hoffnung, dass die restlichen 4TB ausreichen um langfristig kein Performance-Problem zu bekommen. Oder man nimmt zwei ION und schmeißt alle 4 Wochen eine raus und lässt sie rebuilden, falls es doch Probleme dadurch gibt.

 

Beim ASRock scheint das zu funktionieren aber dazu mehr im anderen Thread

 

Ich habe diesbezüglich schon die letzten Tage hin- und her gerechnet allerdings bin ich da zu keinem schlüssigen Ergebnis gekommen bzw. ist daraus meine letzte Idee entstanden. Der SPX Lab hat jetzt diverse Tests durchgeführt und der Vorteil auf der Parity Disc lag lediglich bei ca. 150mb/s dafür ist so eine SSD Konfiguration aber noch einfach zu teuer. D.h. am Ende kommst du an dieser Stelle mit einem Raid 5 SSD System viel besser weg weil du dort Ausfallssicherheit und dann auch richtige Performance hast.

 

Das mit dem fehlenden Trim auf der Parity muss ich mir merken das war mir nicht klar weil ich bisher der Annahme war das dies eine reine HW Thematik von SSD ist?!

[mgutt]

7 hours ago, Smolo said:

Also zieht er jetzt alles aus dem Share per Definition rüber oder nur das was im Zugriff ist?

Alles. 

 

7 hours ago, Smolo said:

Doku

 

Erklärungen bekommst du, wenn du in den Share-Einstellungen auf "Use cache (for new files/directories):" klickst. Das gilt übrigens überall. Oder oben rechts aufs Fragezeichen. Dann werden immer alle Hilfen eingeblendet.

 

7 hours ago, Smolo said:

Eigentlich sollte das Prefer ehr wie ein Festplatten Cache funktionieren bzw. wie bei den anderen Lösungen bei QNAP etc

Deren Caches sind nicht datei- sondern blockbasiert und funktionieren daher nicht ohne die dahinter laufenden HDDs. Ein gänzlich anderes Konzept, das ich nicht haben wollen würde. Aber wie gesagt. Eine "Hot Cache Files" Option wäre schon schick. Kann aber Unraid aktuell nicht. Übrigens erfüllt der RAM diese Aufgabe bereits. Jede Datei, die man abruft, landet bei Linux direkt im RAM. Beim zweiten Download wird gar nicht mehr auf die HDD / SSD zugegriffen. Daher bin ich ein Fan von sehr viel RAM.

 

7 hours ago, Smolo said:

Bei den Dockercontainer kann ich ja kein Limit setzen oder habe ich da was übersehen

Kann nicht gehen, weil die dir dann irgendwann beim Erreichen des Limits abschmieren würden.

 

7 hours ago, Smolo said:

minimum free space

So viel Speicher wird auf der SSD grundsätzlich freigelassen. Das ist notwendig, weil beim Upload auf den Server noch nicht bekannt ist wie groß die Datei wird. Daher muss man diesen Wert größer machen als die größte Datei, die man vor hat hochzuladen. Ich habe wegen Blu-Rip rippen sogar 100GB eingestellt.

 

7 hours ago, Smolo said:

Der SPX Lab hat jetzt diverse Tests durchgeführt und der Vorteil auf der Parity Disc lag lediglich bei ca. 150mb/s

 

Wenn das Array komplett aus SSDs besteht oder wie? Kann ich kaum glauben.

 

7 hours ago, Smolo said:

Das mit dem fehlenden Trim auf der Parity muss ich mir merken das war mir nicht klar weil ich bisher der Annahme war das dies eine reine HW Thematik von SSD ist?!

 

Nein Trim ist Teamwork zwischen OS und SSD. Das OS sagt mit Trim, dass zb Sektor 1 nicht mehr benötigt wird. Sektor 1 liegt auf der SSD aber nicht in Sektor 1 wie bei einer HDD, sondern in einer Gruppe von Sektoren, die sich Seite nennt. Durch den Trim weiß die SSD nun, dass sie zb nun zwei halb volle Seiten zu einer vollen Seite machen kann.

 

Wenn man dagegen einen bestimmten Sektor geändert haben möchte, was ja bei der Parität grundsätzlich der Fall ist, wäre das sehr langsam, weil immer die ganze Seite neu erstellt werden muss. Die SSD lässt das daher gar nicht erst zu und markiert stattdessen den Datensatz auf der Seite als gelöscht und schreibt die Änderung auf eine neue Seite.

 

Daher ist nun meine Hoffnung, dass eine übergröße SSD als Parität, genug Bereiche für diese Aufgabe frei hat und dann bei der Garbage Collection die Daten wieder auf einer Seite zusammenfasst, so dass wieder genug leere Seiten frei werden.

 

Dieser Artikel erklärt das ganz gut:

https://hardwrk.com/blog/trim-vs-garbage-collection-was-ist-der-unterschied

 

Trim funktioniert also nur bei einem klassischen Dateisystem, wo das OS der SSD sagt, dass ganz bestimmte Sektoren einer gelöschten Datei nicht mehr benötigt werden. Da eine Parity aber kein Dateisystem verwendet (Raw) und grundsätzlich immer alle Sektoren in Benutzung sind, kann man hier gar kein Trim anwenden.

 

Erst dachte ich, dass eine übergroße SSD helfen müsste, aber dann müsste es dieses Problem auch bei einem RAID geben. Und hier meinen manche, dass es das dank over-provisioning, also den Ersatzzellen, nicht gibt:

https://www.spinics.net/lists/raid/msg40916.html

 

 

[Smolo]

57 minutes ago, mgutt said:

Erklärungen bekommst du, wenn du in den Share-Einstellungen auf "Use cache (for new files/directories):" klickst. Das gilt übrigens überall. Oder oben rechts aufs Fragezeichen. Dann werden immer alle Hilfen eingeblendet.

 

Ja ich nutze das schon aber mir ergeben sich immer neue Detailfragen die dort natürlich nicht beantwortet werden insbesondere was dies in der Praxis bedeutet daher muss ich euch noch bissel nerven 🙂

 

Quote

So viel Speicher wird auf der SSD grundsätzlich freigelassen. Das ist notwendig, weil beim Upload auf den Server noch nicht bekannt ist wie groß die Datei wird. Daher muss man diesen Wert größer machen als die größte Datei, die man vor hat hochzuladen. Ich habe wegen Blu-Rip rippen sogar 100GB eingestellt.

 

 

Die Cache Disc wird ja von unterschiedlichen Shares befüllt daher hat mich diese Minimumangabe da ziemlich aus dem Konzept gebracht. Wenn ich jetzt bei allen Shares 100GB einstelle wird das immer noch auf die Disc und nicht das Share wirken korrekt?

 

Quote

Wenn das Array komplett aus SSDs besteht oder wie? Kann ich kaum glauben.

 

Hier die Artikel:

NVMe Parity vs HDD Parity in Unraid — SPX Labs

 

All NVMe SSD Array in Unraid — SPX Labs

 

SSD Parity vs HDD Parity vs SSD Array in Unraid — SPX Labs

 

Quote

Daher ist nun meine Hoffnung, dass eine übergröße SSD als Parität, genug Bereiche für diese Aufgabe frei hat und dann bei der Garbage Collection die Daten wieder auf einer Seite zusammenfasst, so dass wieder genug leere Seiten frei werden.

 

Das bleibt ein spannendes Thema bezüglich Fotos etc. werd ich dann probieren auf ein günstige SSD Lösung zu schwenken bei den anderen Daten ist mir das relativ egal. weil es nicht so viele sind oder eben nicht auf den Speed ankommt.

[mgutt]

39 minutes ago, Smolo said:

Die Cache Disc wird ja von unterschiedlichen Shares befüllt daher hat mich diese Minimumangabe da ziemlich aus dem Konzept gebracht. Wenn ich jetzt bei allen Shares 100GB einstelle wird das immer noch auf die Disc und nicht das Share wirken korrekt?

 

 

Ach du nutzt 6.9.0. Da ist das ja jetzt bei den Shares. Bei 6.8.3 konnte man das nur global einstellen. Ich meine aber, dass das nun nicht Share-bezogen ist, sondern Pool-bezogen. Dh wen du jetzt zB 10GB einstellst und die Einstellungen von einem anderen Share lädst, sollte da auch direkt 10GB stehen. Der Sinn dahinter ist, dass man jetzt für jeden Share theoretisch einen eigenen SSD Pool als Cache angeben kann. Das was du willst ist es also nicht.

 

1 hour ago, Smolo said:

Hier die Artikel:

 

Da stört mich einiges:

1.) Er hat auf /mnt/user kopiert und nicht auf /mnt/disk1 (er nimmt dadurch den SHFS Overhead voll mit, der je nach CPU einen Kern überlasten kann)

2.) Er hat scheinbar kein Turbo-Write (reconstruct write) aktiviert, was wohl der größte Fehler darstellen würde.

3.) Bei NVMe only hat er nicht ohne Parity gegengeprüft. Er muss doch erst mal ermitteln ob eine NVMe alleine die 40GB überhaupt mit voller Geschwindigkeit schreiben kann.

4.) Er hat nicht verstanden, dass Trim nicht hilft (weil es auf der Parity nicht greift)

5.) Er hat nach dem Parity Build nicht abgewartet, damit die Garbage Collection die NVMe säubern kann (er hat es zumindest nicht erwähnt). Wenn das Array aus gleich großen NVMe besteht und die Parity gerade erstellt wurde, dann ist der Overprovisioning-Bereich doch bestimmt voll.

6.) Er hat nicht auf mehrere Laufwerke gleichzeitig geschrieben. Da ist das Unraid Array nämlich sehr schwach. Ein Vergleich wäre sehr interessant gewesen.

7.) Es ist sehr verdächtig, dass er eine durchgehend konstante Übertragungsrate hat. Wenn ich 50 GB auf eine HDD meines NAS übertrage, sieht das erst so aus:

 

und nach 25GB so:

 

Um eine durchgehend konstante Übertragungsrate zu erzwingen, müsste ich das RAM Caching von Linux quasi deaktivieren. Wenn er das gemacht hat, warum erwähnt er es nicht?

 

[Smolo]

Nein aktuell verwende ich auch die Stable 6.8.3 und auch dort kannst du schon das Minimum Free Space pro Share angeben, daher war ich ja so verwirrt.  Das mit den Pools habe ich heute auch gelesen da bin ich mal gespannt.

 

Er hat für die Tests auch Videos eingestellt eventuell hat er dort was dazu gesagt aber soviel Zeit hatte ich leider nicht. Das sein System so langsam war hat mich auch gewundert aber das kannst du besser beurteilen als ich mit meinem Anfängerstatus^^ Eventuell schreibst du ihn einfach mal an wegen dem Thema..

 

Schreibst du da auf ein Prefer Share? Warum hält die Platte überhaupt solange durch?

Edited January 25, 2021 by Smolo

[mgutt]

4 minutes ago, Smolo said:

Nein aktuell verwende ich auch die Stable 6.8.3 und auch dort kannst du schon das Minimum Free Space pro Share angeben, daher war ich ja so verwirrt.  

Oh, sehe ich auch gerade ^^

 

Aber die Erklärung steht doch da:

Quote

The minimum free space available to allow writing to any disk belonging to the share.

 

Das hat also nichts mit dem Cache zu tun, sondern mit der Disk. Die Einstellung soll also verhindern, dass man eine Datei auf die Disk kopiert und die Disk dabei voll läuft. Sie meldet also vorher schon, dass sie voll ist, so dass keine partielle Datei auf der Disk erstellt wird. Real wird wohl eh keiner die volle Kapazität pro Disk ausschöpfen. Aber gut zu wissen, dass man auch das einstellen kann ^^

 

10 minutes ago, Smolo said:

Eventuell schreibst du ihn einfach mal an wegen dem Thema..

Habe ihm schon in den Blog geschrieben. Mal sehen ob er antwortet.

 

[Smolo]

49 minutes ago, mgutt said:

Oh, sehe ich auch gerade ^^

 

Aber die Erklärung steht doch da:

 

Das hat also nichts mit dem Cache zu tun, sondern mit der Disk. Die Einstellung soll also verhindern, dass man eine Datei auf die Disk kopiert und die Disk dabei voll läuft. Sie meldet also vorher schon, dass sie voll ist, so dass keine partielle Datei auf der Disk erstellt wird. Real wird wohl eh keiner die volle Kapazität pro Disk ausschöpfen. Aber gut zu wissen, dass man auch das einstellen kann ^^

 

Habe ihm schon in den Blog geschrieben. Mal sehen ob er antwortet.

 

Oh wei ich glaube jetzt habe ich meinen Denkfehler...die Größe bezieht sich auf die DISC und nicht zusätzlich auf den Cache das habe ich nicht überrissen^^ Danke.

[mgutt]

On 26.1.2021 at 12:04 AM, Smolo said:

Eventuell schreibst du ihn einfach mal an wegen dem Thema..

Er hat übrigens geantwortet. Ihm war nichts bekannt. Er weiß weder wie Trim funktioniert, noch kennt er Turbowrite, noch Direkt Disk Access usw. Ich denke daher, dass da mit den richtigen SSDs und Einstellungen weit aus mehr drin ist.