Fard Dwalling
Commander
- Registriert
- Juli 2007
- Beiträge
- 2.115
xexex schrieb:
Vielen Dank, da schau ich gleich mal rein. :-)
News NAS: QNAP bringt ZFS-basiertes Betriebssystem QuTS hero
- Ersteller Frank
- Erstellt am
- Zur News: NAS: QNAP bringt ZFS-basiertes Betriebssystem QuTS hero
Vielen Dank, da schau ich gleich mal rein. :-)
DiedMatrix
Lt. Commander
- Registriert
- Dez. 2003
- Beiträge
- 1.172
SpicyWolf schrieb:ZFS ohne ECC beim Ryzen?
Sorry Leute aber das ist peinlich...
Für alle die das genauso ankotzt wie mich, könnt ja den Beitrag hier liken und ebenfalls kommentieren, sodass etwas "druck" entsteht.
https://www.facebook.com/QNAPDeutsc...otif_id=1587541506646877¬if_t=feed_comment
@xexex Danke für die Auffrischung, mein direkter Kontakt zu QNAP-Systemen ist etwas her und war damals auch auf die Würfel-Systeme beschränkt. Ich bezog mich ja auch eher auf Privatpersonen und kleinere Firmen. Klar bei größeren Unternehmen, wo ein Backup in Zeitfenster X erledigt sein muss da sind 10G (oder gleich mehrere davon) absolut sinnvoll. Ab gewissen Anforderungen lohnt sich dann aber schon eher ein passender Server z.B. wenn man ein IPMI Remote Management benötigt oder gewisse Supportzeiträume und Fristen benötigt.
computerbase107
Rear Admiral
- Registriert
- Okt. 2007
- Beiträge
- 5.455
Stimmt es noch, das man bei der Erweiterung eines ZFS-Systems zuerst das System "plattmachen" muss und anschließend mit den neuen zusätzlichen Platten dann das ZFS-System wieder neu aufbauen muss ?
Fard Dwalling
Commander
- Registriert
- Juli 2007
- Beiträge
- 2.115
snaxilian schrieb:
Ich würde es eher andersherum sehen. Ob das Backup in 10 min oder 2 Stunden fertig ist, ist mir eigentlich wurscht. Aber die Wiederherstellung im Worst Case einer gesamten 4 TB VM, da wird es dann interessant. Um so schneller um so besser.
snaxilian schrieb:
Das Problem bei "Servern" ist an dieser Stelle leider simpel, schon mal geschaut was einzelne Festplatten oder SSDs für einen Server von Fujitsu, HP und Co. kosten?
Bis heute ist es nun mal so, dass sich die OEMs die Datenträger vergolden lassen und natürlich gibt es auch alle paar Jahre neue Rahmen für die Datenträger, damit man bloß nicht auf die Idee kommt welche von aussortierten Servern zu übernehmen.
SpicyWolf schrieb:Und das wäre aus welchen Grund? Hat QNAP eine magische ZFS Implementierung gefunden? Alle Features die ZFS so attraktiv machen wie Bitrot Erkennung durch Prüfsumme kannst du ohne ECC komplett vergessen.
Nö, funktioniert auch ohne ECC.
ECC ist keine Voraussetzung für ZFS, ECC ist auch kein Heilmittel für defekten Speicher (oder andere Störfaktoren), es können nur ungerade Fehler erkannt werden und nur einzelne Bit Fehler behoben werden... Defekter Speicher sollte sofort ersetzt werden! ZFS ist selbstheilend, bedeutet das es Datenkorruption erkennen und beheben kann, die Wahrscheinlichkeit dass ein identischer Bit Fehler bei der Prüfsummenberechnung 2 mal auftritt läuft gegen 0.
Zuletzt bearbeitet:
xone92
Lieutenant
- Registriert
- Feb. 2010
- Beiträge
- 701
haze4real schrieb:
Absolut korrekt, aber ohne ECC bekommst du nichts von Speicherfehlern mit.
haze4real schrieb:
Die Wahrscheinlichkeit geht sicher gegen 0, Speicherfehler im RAM sind aber eben auch als Doppelfehler möglich und üblich. Und ohne ECC hast du keine Chance...
xone92 schrieb:
Ist so nicht richtig, durch einen Scrub kann eine Korruption auf Speicherfehler hinweisen, der Speicher sollte daraufhin überprüft werden.
xone92 schrieb:
??? keine Ahnung was du mit Doppelfehler meinst, aber die Chance, dass die beim Lesen berechnete Prüfsumme durch einen Speicherfehler, den gleichen Fehler aufweist, wie die gelesene Prüfsumme ~ 0...
Und wie bereits angesprochen ECC kann nur ungerade Fehler entdecken, d.h. ECC bekommt von geraden Fehlern nichts mit.
War es noch nie. Du kannst jederzeit weitere vDevs zu einem Pool hinzufügen. Ebenso kannst du bei bestehenden vDevs nach und nach die einzelnen Disks austauschen und resilvern und anschließend den Pool vergrößern.computerbase107 schrieb:
Du kannst auch lebensmüde sein und einzelne HDDs als Single-vDevs zu einem Pool hinzufügen aber verabschiedet sich eine dieser single-vDevs dann verabschieden sich deine Daten.
Ja, ZFS ohne ECC funktioniert aber ist etwas sinnfrei... Entweder will ich ein Dateisystem mit Fehlererkennung und Korrektur dann macht aber auch ECC Sinn um weitere Fehler zu vermeiden oder ich kann es sein lassen^^
Beim schreiben von Daten laufen diese zuerst durch den RAM und da will man dann natürlich auch Fehler vermeiden. Ob das für einen selbst relevant ist oder nicht muss am Ende jeder für sich selbst entscheiden.
@xexex Ja, Disks direkt von den großen Anbietern sind teurer, in der Tat aber nutzen kann man fremde Disks trotzdem oder nimmt Hersteller die sich nicht so anstellen, wie z.B. SuperMicro und dessen Reseller (wortmann, thomas-krenn, etc). Am Ende ist das halt immer ne Supportfrage. Nutze ich nur vom Hersteller freigegebene bzw. verkaufte Hardware ist dieser in der Pflicht es vollumfänglich zu unterstützen.
Im Zweifelsfall berufen sich vermutlich QNAP, Synology, etc auch auf ihre HCLs und stellen sich quer wenn man Disks verwendet, die nicht auf deren HCLs stehen.
Ab einer gewissen Größe ist der Preis jedoch zweitrangig und schneller und zuverlässiger Support ist wichtiger. Alternativ muss man eben konsequent die Methodik fahren: Hardware und Hersteller ist mir egal bzw. vernachlässigbar wenn ich meine Applikationen und Daten hochverfügbar halten kann. Das sind dann aber auch "Aufwände" und Zielsetzungen wo QNAP oder Synology nicht mehr mitspielen^^
SpicyWolf
Cadet 3rd Year
- Registriert
- Apr. 2012
- Beiträge
- 44
Also du willst uns erzählen es ist besser erst beim Scrub von der Korruption zu erfahren als vorher? Genau so wie deine tolle Rechnung, Nahe Null ist eben nicht Null! Vor allem ist ZFS primär ein Enterprise Dateisystem, da ist eine Reduktion der Anfälligkeit von Bitflips durch ECC ein muss.haze4real schrieb:
SpicyWolf schrieb:
So funktioniert ZFS eben, Scrub ist notwendig um die nachhaltige Integrität des Dateisystems sicherzustellen. Scrub ist ein muss.
SpicyWolf schrieb:
100% gibt es eben nicht...
SpicyWolf schrieb:
Es geht nicht darum ob ECC im Enterprise Kontext sinnvoll ist, es geht darum das ZFS kein ECC benötigt um Datenintegrität sicherzustellen.
Scrubs erkennen schwebende/defekte Sektoren, mehr nicht. Lade ich auf einem System mit ZFS Daten in den RAM, bearbeite diese und speichere diese wieder ab kann ZFS nicht erkennen ob bei der Bearbeitung nicht ein Bitflip im RAM passierte. Oder wenn das System nur als NAS dient folgender Anwendungsfall: Remotesystem fragt Daten an, ZFS liest diese aus den HDDs, liefert Ergebnis aus und packt es in den ARC. Bitflip. Daten werden kurz danach erneut gelesen und dieses mal dann die fehlerhaften Daten aus dem ARC übermittelt.
Ja, 100% gibt's nicht aber 95% ist besser als 90% (beispielhaft und keine vernünftige Studie zur Wahrscheinlichkeit von Bitflips im RAM und Storage gesucht).
Von bereits abgelegten Daten, ja. Bei neu zu schreibenden oder veränderten Daten ist ECC jedoch sinnvoll damit eben ein Bitflip im RAM erkannt und korrigiert werden kann. Werden die Daten dann noch in einem System erzeugt das ebenfalls ECC und ein Fehler erkennendes & korrigierendes Dateisystem verwendet erhöht man o.g. Wert ja vielleicht auf 98%.
Ja, technisch kann man ein ZFS ohne ECC betreiben und es aufsetzen. Wenn man sich bewusst ist wovor es einen dann eben nicht mehr schützt kann man das auch wunderbar so machen. Die wenigsten werden dies vermutlich jedoch in der Tiefe machen, lesen nur ZFS und denken dann dass immer und überall diese Daten sicher sind.
Ja, 100% gibt's nicht aber 95% ist besser als 90% (beispielhaft und keine vernünftige Studie zur Wahrscheinlichkeit von Bitflips im RAM und Storage gesucht).
Von bereits abgelegten Daten, ja. Bei neu zu schreibenden oder veränderten Daten ist ECC jedoch sinnvoll damit eben ein Bitflip im RAM erkannt und korrigiert werden kann. Werden die Daten dann noch in einem System erzeugt das ebenfalls ECC und ein Fehler erkennendes & korrigierendes Dateisystem verwendet erhöht man o.g. Wert ja vielleicht auf 98%.
Ja, technisch kann man ein ZFS ohne ECC betreiben und es aufsetzen. Wenn man sich bewusst ist wovor es einen dann eben nicht mehr schützt kann man das auch wunderbar so machen. Die wenigsten werden dies vermutlich jedoch in der Tiefe machen, lesen nur ZFS und denken dann dass immer und überall diese Daten sicher sind.
@snaxilian Wenn die Daten schon vor dem Schreiben korrupt sind, hilft dir auch kein anderes Dateisystem oder RAID-System weiter... ZFS kann lediglich sicherstellen das bereits geschriebene Daten ihre Integrität bewahren, i.e. Vorbeugung gegen Bitrot, und hierfür benötigt es kein ECC, ergo ECC ist nicht notwendig.
Mit einer Aussage "NAS ohne ECC?" kann ich eher etwas anfangen als mit "ZFS ohne ECC?", daher die Diskussion.
Auch beim Lesen aus dem ARC sollte eine Überprüfung der Prüfsumme stattfinden, bedeutet das in diesem Fall die Daten von der Platte gelesen werden würden.
Mit einer Aussage "NAS ohne ECC?" kann ich eher etwas anfangen als mit "ZFS ohne ECC?", daher die Diskussion.
snaxilian schrieb:
Auch beim Lesen aus dem ARC sollte eine Überprüfung der Prüfsumme stattfinden, bedeutet das in diesem Fall die Daten von der Platte gelesen werden würden.
Zuletzt bearbeitet:
SpicyWolf
Cadet 3rd Year
- Registriert
- Apr. 2012
- Beiträge
- 44
Natürlich ist Scrubben ein muss und trotzdem bleibt die Aussage falsch, nur weil dir die Fehler dann auffallen heißt das noch nicht das die Kacke nicht schon am Dampfen ist.haze4real schrieb:
Ebenso die Logik von 100% gibt es nicht, 99,999% sind immernoch besser als 50% (Zahlen sind an den Haaren herbeigegriffen).
Und warum dann nicht einfach EXT4 oder XFS wenn die Datenintegrität nicht so wichtig ist?
Klar bietet ZFS minimale Integrität durch Checksummen, doch wie schon gesagt ZFS und ECC gehen durch den Ursprung im Enterprise-Bereich Hand in Hand.
F
Faultier
Gast
ZFS ist sehr spannend hat es aber nicht direkt ins Linux geschaft.
https://www.heise.de/newsticker/mel...S-im-Linux-Kernel-erneute-Absage-4633302.html
Ob die 128 Bit so doll sind die Ich hier gelesen hab ist die andere Frage da man AES auch "erst" ab 256 Bit und 4096 Bit Schlüsselänge als sicher ansehen kann.
https://www.heise.de/newsticker/mel...S-im-Linux-Kernel-erneute-Absage-4633302.html
Ob die 128 Bit so doll sind die Ich hier gelesen hab ist die andere Frage da man AES auch "erst" ab 256 Bit und 4096 Bit Schlüsselänge als sicher ansehen kann.
haze4real schrieb:
Zum Überleben eines Autounfalls, bei dem drölf Airbags an allen nur denkbaren Stellen zünden, sind Sicherheitsgurte weder hinreichend noch notwendig. Hochgradig hilfreich sind sie dennoch, und bei einem Fünf-Sterne-NCAP-ZFS-EdelNAS im mittleren vierstelligen Preisbereich gibt es keinen technischen Grund, ECC-Speicher für wortwörtlich Cent-Beträge NICHT zu verbauen.
Wenn ich nicht ganz auf dem Schlauch stehe erkennt und korrigiert ECC 1-Bit-Fehler, und erkennt 2-Bit-Fehler, kann sie aber nur noch melden und nicht korrigieren. Wenn dein RAM völlig hinüber ist bringt das natürlich nichts, aber aus der Luft gegriffene 99% aller zufälligen Fehler sind damit abgedeckt und sich anbahnende Hardwareprobleme können erkannt und gemeldet werden.haze4real schrieb:
ECC-freier Speicher macht genau NICHTS. Erst wenn der Benutzer erkennt, dass hier jenseits von Softwarefehlern mächtig etwas schief läuft, muss manuell getestet werden (wer fährt einen Rechner/Server schon zum wöchentlichen memtest runter?). Bis dahin können TB-weise Daten vermurkst werden und sich schon über die nächsten Backupstufen in die Langzeitarchive gefressen haben.
Nochmal: Wenn das jetzt ein Mega-Enterprisefeature wäre, das die Hardwarekosten mal eben verdoppelt - gut, kann man abwägen. Aber für ein eh ECC-kompatibles System grob vereinfacht 1/9 der Bauteile auf jedem RAM-Riegel zu sparen ist halt hochgradig bescheuert.
Ähnliche Themen
