True Nas Scale Auto-Shutdown

Jo das sicher sinnvoll dann Qualität zu holen bei den Backplates :D die halten auch dann ewig.

Das 719 schaut aber echt gut aus auch was man auf den Bildern sieht schaut Verabeitung und Co echt topp aus, würde mir auch gefallen - ich bin halt auf dem Fractal R5 "hängengeblieben" das halt ein "schlichtes" aber doch auch ein gutes Gehäuse für kleine Heimserver.

Wenn man gebraucht kauft gibt es ECC Ram meist recht günstig wenn auch die unbuffered etwas teurer sind als die reg.

Hehe bei mir ist die Konfiguraiton so dass MINDESTENS 9 HDDs gleichzeitig ausfallen müssen bevor ich auf das Backup zurückgreifen müsste :D das ist ausreichend unwahrscheinlich - 1 Server ist auch räumlich getrennt im Ferienhaus - da per 10 Gbit Glasfaser up/down angebunden ist das aber wie wenn der daheim stehen würde :D - was irgendwie total verrückt ist. Ich habe bei mir PiKVM im Einsatz, weiss nicht ob das kennst? https://pikvm.org/ (die selber bastel Variante) - einfach nur super wenn man Server irgendwo stehen hat wie Keller oder sogar weiter entfernt - ich finde das besser als IPMI, vor allem da OpenSource.

Immerhin ZFS nimmt nur einen Rebuild in dem Bereich vor, der tatsächlich mit Daten belegt ist - und man hat gleichzeitig dann auch einen Komplettcheck aller Daten auf CRC etc.
 
Bohnenhans schrieb:
Das 719 schaut aber echt gut aus
Das war vorher mein Gaming PC und ich habe den für 189 euro gekauft. Für den Preis is das Absolut viel gehäuse. Fand den echt hammer.
Das R5 war vorher mein Server Case. Nur wurde das zu klein.
Bohnenhans schrieb:
Wenn man gebraucht kauft gibt es ECC Ram meist recht günstig wenn auch die unbuffered etwas teurer sind als die reg.
Das Problem mit dem ECC. Ja den hätte ich längst, nur gibts für mein Board keine QVL oder überhaupt irgend einen Hinweis welche Riegel da jetzt gehen könnten. Ich nutze das mit nem Ryzen 3900x aber auf gut glück hab ich kein Bock Ram zu kaufen. Is halt Consumer Hardware... aber da biste, auch wenns die Ryzen können, ganz schön allein gelassen. Asus schreibt nur nen Einzeiler, das es von der CPU Abhängt. Die Info bringt einem halt nix.

Deshalb bleibt die Kiste erst mal ohne ECC. Und bringen tuts das eh nicht im heimgebrauch. Dazu müsstest ja ECC in den Klienten haben, und du müsstest auch bei jedem Kopieren per Checksum prüfen ob die files die du abgeschickt hast auch so angekommen sind. Der Aufwand rentiert gar nicht. Zumindest bei mir. Du minimierst lediglich einen winzigen schritt innerhalb des servers bei ZFS mit ECC ram. Alle anderen Wege die die Daten bis dahin unternehmen werden dabei 0 berücksichtigt. Deswegen meine ich halt, das der Einsatz mit ECC so nicht zu ende gedacht is. Die Ganze Kette muss es tun.
 
Naja das macht aber doch TCP dass es die Pakete checksummt oder? So erkennt es doch defekte Pakete bei der Übertragung und fordert die wieder neu an - der Übertragunsgweg selber denke ich ist ganz gut gesichert.

Sicher ist das nur ein sehr kleines Plus sowas wie z.B. "Seatbeltairbags oder Kneeairbags" aber die Frage ist halt wieso drauf verzichten selbst wenn es nur in 1% der Fälle was bringt das ist doch der Aufpreis - wenn man nicht die aktuellste Hardware will - meistens wert.

Mein "neuester" Server wurde von dem Anbieter am Ende mit Supermicro X11 Board, Xeon V5 CPU und 64 Gb ECC DDR4 für zusammen glaub 150? Euro "in Massen" verkauft (mit Gehäuse und Seasonic Netzteil) - bei solchen Preisen verzichte ich halt nicht auf etwas mehr Sicherheit. auch wenn es wenig Sicherheit mehr ist.
 
Jo.
Sollte bei meinem jetzigen irgendwann mal n upgrade fällig werden nehme ich ECC auch mit, klar. Aber für den jetzigen würd ich quasi nich den aufwand betreiben nach passenden ram zu suchen. Das meinte ich.

Irgendwann soll der Kram ja auch mal in ein rack Gehäuse usw. Aber das auch mehr aus lust an der Spielerei als das es nötig is. Wenn mal n upgrade auf AM5 oder sogar AM6 fällig is oder intel wird ja glaub ich ECC eh standard. Von daher mach ich mir da erst mal keinen Kopf.

Bohnenhans schrieb:
Naja das macht aber doch TCP dass es die Pakete checksummt oder?
Naja, das weiß ich nicht. Wenn ich bsp. mit Terra Copy mittels checksum kopiere sehe ich im Netzwerk schon eine erhebliche Änderung in Sachen senden und empfangen. Da wird schon aktiv die Gegenstelle mit dem sender überprüft. Sprich die Auslastung is in beide Richtungen ausgelastet.

Wenn ich "einfach" kopiere, wird nur gesendet, nichts gelesen. Müsste mich mal da genauer reinlesen aber entweder macht das TCP dann on the fly bit für bit oder eben nich. Keine Ahnung. Erfahrungsgemäß würde ich aber behaupten das es das nich kann.

Hatte mal vor Jahren, als es noch Gameload gab mir Sacred 2 laden wollen. Waren 6 Archive. Kaman alle immer beschädigt an. Hab dann von der Telekom das Spiel auf DVDs zugeschickt bekommen und im Anschluss wurde n Verteiler repariert der dafür sorgte das packets defekt ankamen. Da wären wohl einige Ports hinüber gewesen so deren aussage.
Bohnenhans schrieb:
Mein "neuester" Server wurde von dem Anbieter am Ende mit Supermicro X11 Board, Xeon V5 CPU und 64 Gb ECC DDR4 für zusammen glaub 150? Euro "in Massen" verkauft (mit Gehäuse und Seasonic Netzteil)
Ja da hätte ich wohl auch zugeschlagen. :D Kein Frage. Was man mitnehmen kann, auf jeden fall.
 
Die Berechnung der Prüfsumme für IPv4 ist in RFC 793 definiert:[4] sagt Wikipedia

„Die Prüfsumme ist das 16-Bit-Einerkomplement der Einerkomplement-Summe aller 16-Bit-Wörter im Header und der Nutzdaten des unterliegenden Protokolls. Wenn ein Segment eine ungerade Anzahl Bytes enthält, wird ein Padding-Byte angehängt. Das Padding wird nicht übertragen. Während der Berechnung der Prüfsumme wird das Prüfsummenfeld selbst mit Nullen gefüllt.“


Sonst hätte man auch beim Internet z.B. mobil sicher sehr viele Fehler gäbe es da keine Fehlererkennung und Mechanismen zum Autoresend.

Auch das darunterliegende Ethernet etc hat zusätzlich davon unabhängige Prüfsummen https://de.wikipedia.org/wiki/Blockprüfzeichenfolge z.B. für JEDEN Ethernetframe.

Checksummen werden doch seit Jahrzehnten ganz oft überall verwendet wenn es um Übertragung geht, das ja weder ein nenneswerter Speicher noch Rechenaufwand. Für ausreichend sichere Fehlererkennung reichen ja extrem einfache Verfahren.

Klar ist ECC nicht extrem wichtig weil > 2 Bit Fehler werden glaub auch nicht sicher erkannt. aber es ist halt nice-to-have. Extra wechseln würde ich auch nicht - ich würde halt das verbaute RAM 1x mit so einem RAMTest komplett über Nacht durchtesten - und dann erst wieder wenn ZFS CRC Fehler meldet, denn das würde das ja merken dass da was nicht passt sobald es bestehende Daten liest und sich der Speicherfehler auswirkt.

Der Vorteil ist ZFS versuscht das dann nicht zu verschlimmbessern sondern meldet nur da passt was nicht - also alles dann safe.

Die Gefahr ist also extremst gering das ZFS bei einem Speicherfehler Daten kaputtmacht - wegen hash collision vielleicht im 1: 1 Billiarden Bereich oder so xD

Hehe ich habe auch einen ECC Riegel der tatsächlich einen Bit-Fehler hat - finde ich praktisch um zu testen wie man die BIT Fehler dann per Software auslesen kann in Linux/FreeBSD/Windows etc. ("leider" nur einen DDR3 ECC mit Fehler, aber denke auf ebay etc findet man evtl auch einen mit DDR4)
 
Zuletzt bearbeitet:
Bohnenhans schrieb:
Klar ist ECC nicht extrem wichtig weil > 2 Bit Fehler werden glaub auch nicht sicher erkannt.
Ja bei den Ram Typen kenn ich mich nich so genau aus. Es gibt soweit ich weis SingleBit Correction und Mutlibit, aber ich hab keinen Dunst welcher besser is.

Ich würd ja gern auf 128gb aufrüsten. Ich frag mich halt, muss man die in nem Kit Kaufen oder gehen die dann auch wenn die nicht in einem kit sind. Ka ob da ECC UDIMM Ram da anders fungiert.

Aber wie gesagt, zum testen welcher ram geht is halt zu kostspielig. Ich hab leider auch kaum Ansätze im Netz gefunden die hfilreich sind weil halt echt jeder andere Konstellationen nutzt. Theoretisch müsste das Board ja egal sein weil der MC in der cpu sitzt. Aber bei ECC spielt das Mobo schon eine rolle irgendwo meine ich gelesen zu haben.

Wird halt nirgends getestet.

Bohnenhans schrieb:
Der Vorteil ist ZFS versuscht das dann nicht zu verschlimmbessern sondern meldet nur da passt was nicht - also alles dann safe.
Habe ich eben festgestellt. Beim Austauschen der zwei meckernden HDDs mit den CRC errors wurde eine Datei beschädigt. Es handelte sich dabei um eine 10TB vm hdd. Es war nur die Backup Datei innerhalb vom Unraid. Die hab ich angelegt weil ich da auch mal eine zerlegt hab XD.

Wird gerade neu erstellt, andernfalls wäre die noch auf dem zweit Server gewesen. Der Fehler wurde quasi beim Rebuild gemeldet als die CRC Fehler nach oben schossen. Als ich dann die Platten per Preclear komplett gewipet habe (anderer Kabel und Controller) wurde das nicht besser. Manchmal hilft das wenn die HDD die Sektoren umleiten kann. Hier wohl nicht mehr. Aber nach über 15 Jahren darf die in Rente.

Die Platten landen auf dem Wertstoffhof.
 
Ja ab und zu muss auch eine HDD in Rente bzw zum Recycling :D

10 TB Files sind natürlich auch krass grosse Brocken :O
 
Bohnenhans schrieb:
10 TB Files sind natürlich auch krass grosse Brocken :O
ja is quasi ne VHD auf der die SteamBibliothek der VM läuft. Man kann zwar nen Share auch in die vm durchreichen, aber die Performance is unterirdisch. Is auch die einzige die so fett is. Die is auch nur semi wichtig, Dienst ja nur als Download cache wenn man so will.
 
Hmmm irgendwas passt mit dem Script noch nicht ganz - ich hatte das jetzt 2x dass das Script irgendwann aufgehört hat zu arbeiten.

ich hab jetzt mal viel mehr Debug Ausgaben reingemacht um zu sehen wo das passiert..... so direkt habe ich nichts gefunden.... so ganz habe ich gerade keine Idee woran das liegt - das LOG-File wird auch max 2x8 MByte gross ..... 32 Gbyte sind frei auf /tmp/
 
Zuletzt bearbeitet:
Okay. Ja ich bin noch nich wirklich weiter gekommen mit dem TrueNas Server. Ich hab grad Spielerein probiert irgendwie ne Unraid VM aufzusetzten damit ich testen kann ob ich den Pool einfach Importieren kann. Unraid nutzt ja n anderes Partitionslayout als TrueNas.

Nur mal gucken was möglich ist, weil den ganzen Pool irgendwo zwischen zu lagern dürfte sich als Schwierig herausstellen. Aber Danke für das Update.
 
Hmmm ja ist bei Unraid das ZFS dann erst oberhalb der Verteilstruktur auf die HDDs? muss doch fast so sein oder?

ZFS würde doch die Daten anders verteilen als UNRAID?

Ich nutze halt lieber "plain" ZFS so wie in TrueNAS dann kann ich halt einfach per Linux, FreeBSD, MacOS oder prinzipiell auch Windows darauf zugreifen. Das idn ich halt schon sinnvoller - Nachteil ist halt das mit dem HDD selektiv abschalten etc - aber HDD Sleep hab ich eh nie genutzt.

Ich bin mal echt gespannt wo das Script ab und zu aussteigt oder wieso das beendet wird - ist halt leider so selten, dass ich das nicht einfach reproduzieren konnte - denke mit den ganzen Debug "Ausgabezahlen" lässt sich das dann hoffentlich eingrenzen.

-----------------------------------------------------------------------------------------------------

Hier blieb es stehen und zwar bei debugPrint "16" der nächste debugPrint wurde nicht ausgeführt.

myDataCounter hatte den Wert 512 (2 * 256) das hochzählen auf 513 hat nicht geklappt auch wenn das sonst eigentlich fast immer funktioniert und zuvor hat er natürlich auch in diesem Durchlauf ganz normal von 0 auf 512 hochgezählt......

Ich muss mal schauen ob das nur Zufall war evtl killt TrueNas ja auch aus irgendeinem Grund den Task... ich erfasse jetzt auch mal die Uhrzeit mit, vielleicht ist da irgendwas zu sehen.

Code:
  debugPrint "16"

   myDataCounterOK=$(($myDataCounterOK+1))
   debugPrint "[AUTOSHUTDOWN] $myDataCounterOK von $myNumberOfRetries Durchlaeufen fuers Runterfahren"

   if [ $myDataCounterOK -gt $myNumberOfRetries ]; then
      debugPrint "[AUTOSHUTDOWN] Fahre System herunter...."
      /usr/sbin/shutdown -h now
#      exit 0
fi
 
Zuletzt bearbeitet:
Bohnenhans schrieb:
Hmmm ja ist bei Unraid das ZFS dann erst oberhalb der Verteilstruktur auf die HDDs? muss doch fast so sein oder?
Kann ich dir nicht genau sagen. Ich habe nur mal n paar chats mitverfolgt wo Leute eben ihren ZFS in Unraid Importiert haben. Und da meinte einer das bei Truenas ZFS irgendwie die erste Partition is und bei Unraid aber auf der zweiten. Bitte frag nich nach details, weil so genau weiß ich das auch nicht. Es scheint aber irgendwie unter Unraid anders eingestellt zu werden als bei TrueNas. Zumal Unraid das auch stark anpasst.

Aber was die damit gemeint haben keine ahnung.
 
Habe mir das mal genauer angeschaut glaube das müsste das reparieren

Code:
myDataCounterOK=$((myDataCounterOK+1))
sein statt
myDataCounterOK=$(($myDataCounterOK+1))

Obwohl das wohl meistens tutet aber halt eigentlich nicht richtig war....
:)Hihi da muss ich mir noch andere scripte anschauen, in denen ich rechne

Interessant ist halt kann man unraid sets woanders importieren?
 
Zuletzt bearbeitet:
Bohnenhans schrieb:
Interessant ist halt kann man unraid sets woanders importieren?
Auf die Idee bin ich noch nich gekommen :D. Naheliegenste war für mich unraid in ner vm XD Aber irgendwie will das nicht starten in einer vm.
 
Mit virtualbox?
 
Ne ich hab direkt in unraid ne VM gemacht. Weil dort ja dann auch die virtuellen Pools liegen. Ja... virtual box wäre evtl. dann auch ne option XD. Daran habe ich auch nicht gedacht. Er bootet zwar nen stück und jammert oder hängt dann irgendwo bei checksum. Kann auch gut sein das der durchgereichte sitck im arsch is. Hab keine mehr über die ich entbehren kann.
 
Hmmm evtl test ich das mal mit pkvm kann ich ja eh nen virtuellen stick machen und 1 server bekommt aktuell noch ein paar hdds zusätzlich - ist also sowieso im umbau
 
Naja unraid verlangt ne UID oder so vom Stick. Wennst das vortäuschen kannst. Evtl. komme ich am Wochenende dazu das nochmal anzugehen.
 
Ja glaub pikvm emuliert den stick vollständig - da wird ja sowieso das komplette usb handling per software emuliert
 
Ja ich hab in unraid einfach den ganzen USB Controller durchgereicht. Aber keine zeit gehabt das am Weekend durchzugehen. Und unter der Woche zurzeit eher weniger zeit weil viel los is.
 
Zurück
Oben