NAS. Nicht populär?

Siehe auch restlicher Kommentar ;)

Ich hab da halt gerne mal schnell zum Test was drauf was ich nicht direkt auf einen Webspace/Server packen will.
Dafür ist so ein NAS auch super.

Und ja natürlich kann man das auch anderweitig realisieren. Nur eben auch i.d.R. mit höheren Aufwand.
Ich bin selten ein Freund von KlickiBunti, aber da passt es einfach.

Oder sagen wir es so:
Qnap hat es leider irgendwann verschlimmbessert. Zumindest vor ~1 1/2 Jahren war ich da auch nicht mehr so zufrieden.
Aber Synology ist bisher super und bringt auch stetig gute Verbesserungen.
 
Zuletzt bearbeitet:
Die haben mittlerweile glaube ich jede Menge Pakete die man schnell installieren kann und dann in der GUI einfach einrichten. Aber es gibt halt auch viele die nur SMB und vielleicht noch DLNA/UPNP brauchen. Vom letzteren halte ich auch überhaupt nichts, dass ist eine Krankheit die sich ausbreitet. Da tuts dann auch das Teil von Zyxel und das ist auch in 5min eingerichtet, kostet aber die Hälfte.
 
Auch da musst du immer die Software bedenken.
Wenn man rein die Hardware nimmt sind Zyxel und andere Hersteller deutlich günstiger gar keine Frage. Von der reinen Leistung her dürften sie auch identisch sein bei ähnlicher Hardware.

Aber je nach Anwendungungsfall, den man halt immer bedenken muss, bieten Qnap und Synology da mehr da sie mehr mit anderen Softwareherstellern zusammenarbeiten.
Hier halt nur mal das Beispiel Plex (ist halt eine Anwendung die ich nutzen, gibt auch andere): das gibts offiziell nicht für Zyxel.
Man kann jetzt suchen und findet womöglich irgendwo eine Lösung die man selber kompilieren muss oder ggf. sogar jemand der schon mal gebastelt und kompiliert hat. Aber das ist eben wieder mit Zeit&Aufwand verbunden.

Man vergleiche auch einfach mal die Foren zu den Geräten bzw. Herstellern was da los ist, was möglich ist usw. usw.

Ud nur um es nochmal rauszustellen:
- Ich bin auch absolut der Meinung das Selbstbau in vielen Bereichen, rein von der Hardware her, deutlich günstiger sein kann als ein Fertigprodukt
- Ich bin ebenfalls der Meinung das die Platzhirsche Qnap und Synolgy nicht gerade günstig, ja wenn nicht gar etwas überteuert sind und man in diversen Fällen, wenn man nicht selber bauen will/kann, auch mit einem günstigen NAS sehr gut leben kann. Die Geräte von Qnap und Synology bringen da halt ggf. etwas mehr Luxus mit, der aber natürlich nicht sein muss
- Jedoch stimme ich ungern in den Tenor mit ein das ein Fertigbau-NAS grundlegend immer überteuert und sinnlos ist und ebenso finde ich halt auch die großen Anbieter nicht grundlegend völlig überteuert weil ich halt diverse andere Faktoren mit einbeziehe die für mich und mein Anwendungsgebiet wichtig sind
 
Wie kommst du darauf, dass ein Fehler im RAM sich durch Scrubbing im Dateisystem fortsetzen würde?
Lies mal dies hier:

Und überdenke Deine Aussage noch einmal. RAM Fehler beim Scrubbing können Deinen Pool zerstören, ich hoffe für Dich das ZFS es Dir nie beweisen wird.

Im Gegenteil, das Scrubbing würde einen Fehler aufdecken, der vorher im RAM passiert ist und nicht durch andere Schutzmechanismen (z.B. ECC) abgefangen wurde.
Das kann es doch gar nicht, weil es ja nicht weiß, ob der Fehler im RAM oder von der Disk kommt und da es eben für ECC RAM entwickelt ist, wird es den Fehler immer in der HDD vermuten.
ZFS hängt nicht im geringsten von ECC-RAM ab, ebenso wie Btrfs übrigens auch nicht.
Hast Du Belege dafür? Hie von einem führenden Mitglieder der FreeNAS Community:
Lies Dir das durch, da steht auch wieso Scrubbing den Pool zerstört und es folge auch den Links dort, da gibt es Beispiele dafür. Das Problem ist, dass ZFS das RAM sehr intensiv nutzt und wenn beim Lesen ein Fehler aufgrund eines RAM Fehlers erkannt wird, weil eben im RAM nicht mehr steht was auf der Disk steht, dann wird ZFS diesen Fehler der Disk zuschreiben und dort die vermeindlich fehlerhaften Daten "korrigieren", nur sind die ja scheinbar korrekten Daten eben falsch und beim Lesen korrupt geworden.

Was da bei einem normalen RAID passiert möchte ich mir nicht ausmalen.
Das hängt davon ab ob es ein HW-RAID ist, dann hat der Controller i.d.R. die entsprechende Sicherung gegen RAM Fehler im Cache und bei normalen Filesystemen bleibt der Fehler erstmal unentdeckt, wie fast alle RAM Fehler, weshalb diese auch so unterschätzt werden:
Da es keine Prüfsummen gibt, fällt der Fehler halt nur auf, wenn das Programm mit der Datei nichts anfangen kann oder vielleicht der Rechner abstürzt. Manchmal hat man auch Datenverlust, weil die Metadaten des Filesystems betroffen sind und schon wird eine Datei oder ein ganzer Ordner nicht mehr angezeigt, oder es werden Datein von der falsche Stelle gelesen, je nachdem welche Information durch den Fehler falsch geworden ist.
Habe z.B. eine Samsung/Seagate F4 (immer die gleiche) wo ab und an ein Bitfehler auftritt und nach einem Resilver ist wieder alles ok.
Wenn hier jemand ein gekipptes Bit in den Dateien hat, dann dürfte es sehr, sehr wahrscheinlich ein RAM Fehler sein, denn bei Consumer HDDs liegt die Rate der unkorrigierbaren Bitfehler i.d.R. bei 1:10^14 Sektoren pro gelesenes Bit, also etwa einer pro 12TB und dann gibt es einen Lesefehler, also i.d.R. einen schwebenden Sektor und übliche Windowsprgramme sollen diesen Lesefehler anzeigen und den Vorgang abbrechen. Die Rate der unerkannten Bitfehler, also wenn die ECC den Fehler nicht erkennt und die falschen Daten als korrekt übernimmtelt, sind noch viel, viel seltener. Ansonsten könnte es noch ein Fehler in den internen Datenpfaden der Platte sein, bei einige Conusmer Platten gibt es dafür eine End-to-End Error Attribut in den S.M.A.R.T. Werten, andere sichern die Daten in den Datenpfaden nicht ab, Enterprise Platten machen das immer und auch entsprechend aufwendiger.

Kann nicht passieren. Die Prüfsummen zeigen nur an, dass etwas falsch ist. Sie können nicht zur Korrektur heran gezogen werden.
Wobei Du einmal übersieht, dass die Dateien dann schon korrupt sein können, wenn die Prüfsumme über die korrupte Datei geblidet wurde und zum anderen das es beim Scrubbing eben nicht dabei bleibt das nur ein Fehler erkannt wird, es wird natürlich versucht ihn zu korrigieren und damit beginnt der nächste Akt des Dramas.

Auf das Srcubbing zu verzichten ist übrigens auch keine gute Idee, denn es dient dazu die schlechtende Fehler auf der Platte zu erkennen und zu korrigieren, denn wenn das zu viele werden und irgendwo mal Daten und deren Parity betroffen sind, dann sind die Daten auch verloren.

Aber das muss jeder selbst entscheiden, ich würde ohne ECC-RAM keinen Fileserver bauen wollen, schon nicht ohne ZFS und noch weniger mit ZFS, wenn mir meine Dateien wichtig sind.
 
Lies mal dies hier:

Und überdenke Deine Aussage noch einmal. RAM Fehler beim Scrubbing können Deinen Pool zerstören, ich hoffe für Dich das ZFS es Dir nie beweisen wird.
Wenn das wirklich so ist, ist ZFS broken by design. Glaube ich ehrlich gesagt nicht.

Das kann es doch gar nicht, weil es ja nicht weiß, ob der Fehler im RAM oder von der Disk kommt und da es eben für ECC RAM entwickelt ist, wird es den Fehler immer in der HDD vermuten.

Hast Du Belege dafür? Hie von einem führenden Mitglieder der FreeNAS Community: Lies Dir das durch, da steht auch wieso Scrubbing den Pool zerstört und es folge auch den Links dort, da gibt es Beispiele dafür. Das Problem ist, dass ZFS das RAM sehr intensiv nutzt und wenn beim Lesen ein Fehler aufgrund eines RAM Fehlers erkannt wird, weil eben im RAM nicht mehr steht was auf der Disk steht, dann wird ZFS diesen Fehler der Disk zuschreiben und dort die vermeindlich fehlerhaften Daten "korrigieren", nur sind die ja scheinbar korrekten Daten eben falsch und beim Lesen korrupt geworden.
Du weißt schon, wie die Fehlererkennung und Korrektur funktioniert? Scheint mir nämlich nicht so. Und von dir zitierter Admin aus dem FreeNAS-Forum scheint auch nicht wirklich Ahnung zu haben. Denn so, wie er es beschrieben hat, kann der Fehler sich nicht fortpflanzen, sondern würde zu seiner ursprünglich korrupten Form "korrigiert" werden. Andernfalls wären wir wieder beim Punkt, dass ZFS broken by design wäre. Kann ich jetzt nicht beurteilen, da stecke ich nicht tief genug drin. Ich kann es aber für Btrfs sicher sagen, dass es dort korrekt behandelt wird. Bei ZFS vermute ich es nach meinem aktuellem Kenntnisstand auch.

Update: Der angenommene Bitfehler im RAM würde übrigens innerhalb kürzester Zeit einen immensen Schaden anrichten, unabhängig vom verwendeten Dateisystem. Wie schon gesagt, cachen heute alle System mehr oder weniger exzessiv. Wenn da eine Zelle permanent Fehler produziert, ist die Wahrscheinlichkeit extrem hoch, dass sich das auf Fehler im Dateisystem niederschlägt.
Solche Fälle gab es übrigens schon, bei denen Btrfs den Fehlerhaften RAM aufgezeigt hatte. Und es war genau diese hier kritisierte Fehlerkorrektur, die das dort erreicht hat. ;)
 
Zuletzt bearbeitet:
broken by design würde ich nicht sagen, es ist ein Filesystem welches für Serverumgebungen entwickelt wurde und dort ist ECC RAM Pflicht, von Anpassung an HW ohne ECC wäre mir nichts bekannt und für so eine HW sollte man ZFS eben besser nicht nutzen, wobei ich auch bei allen anderen Fileservern keine HW ohne ECC RAM nutzen würde weil ich wert auf Datennitegrität lege, weshalb ich stett eines fertigen NAS einen N54L Microserver gekauft habe.
 
Das ist aber dann auch der falsche Einsatzzweck und man könnte eine USB Platte an den Router hängen.
Einen Router der an der eigenen Buchse NTFS mit mehr als 10 MB/s lesen und mehr als 5 MB/s schreiben kann, hab ich leider noch nicht gesehen. Beide Werte kann man eigetnlich noch locker halbieren ;)

Sonst denke ich bekommen die Leute auch Unlust wegen der Administration -> Oder schnell Kopfschmerzen, wenn sie anfangen zu forschen wie man es zusammenbastelt, damit man auch noch am selfmade-NAS einen Monitor, Tasta und Maus stellen können. Beim NAS sind sie halt sofort per Webinterface drin und dabei.
einer der seltenen Fälle wo man sich Lebenszeit für was anderes mit (mehr) Geld erkauft.

@OnkelHomie
Entsprechend billigere Zyxel sind merkbar lauter und deutliche lahmer. 1x 1.6Ghz oder 2x 800Mhz Kisten mit Marvel/ARM kann man auch bei einer Platte vergessen.
 
Zuletzt bearbeitet:
Einen Router der an der eigenen Buchse NTFS mit mehr als 10 MB/s lesen und mehr als 5 MB/s schreiben kann, hab ich leider noch nicht gesehen. Beide Werte kann man eigetnlich noch locker halbieren ;)

Das meinst Du jetzt doch nicht etwa ernst oder ?
Ich weis ja nicht was Du als Router nennst, aber mein TP-Link kommt da locker drüber ???
 
@OnkelHomie
Entsprechend billigere Zyxel sind merkbar lauter und deutliche lahmer. 1x 1.6Ghz oder 2x 800Mhz Kisten mit Marvel/ARM kann man auch bei einer Platte vergessen.

Die kleinen Qnaps oder Synologys, die auch mal in ähnlichen Preisregionen sind wie die Zyxel Kisten, also so um die 150€, haben gerne mal nur 1x800 MHz oder 2x800MHz ARM/Marvell. Und genau deshalb bin ich auch auf eine vernünftige X86 Plattform umgestiegen.

Wenn man nur hier und da mal Daten auslagern will reichen die kleinen Kisten aus. Ansonsten muss man unter 250€ bei den "Premium Herstellern" erst gar nicht gucken meiner Ansicht nach. Mein DS214play hat inkl. 2x2TB WD Red damals meine ich 400€ gekostet, das NAS selbst lag halt bei ~300€.
 
broken by design würde ich nicht sagen, es ist ein Filesystem welches für Serverumgebungen entwickelt wurde und dort ist ECC RAM Pflicht, von Anpassung an HW ohne ECC wäre mir nichts bekannt und für so eine HW sollte man ZFS eben besser nicht nutzen, wobei ich auch bei allen anderen Fileservern keine HW ohne ECC RAM nutzen würde weil ich wert auf Datennitegrität lege, weshalb ich stett eines fertigen NAS einen N54L Microserver gekauft habe.
Also ich würde schon sagen, dass ein Dateisystem, welches die Fehler vervielfältigt, broken by design ist. Dass ZFS für ECC-RAM entworfen wurde, behauptest du immer wieder. Einen Nachweis habe ich noch nicht gesehen. Dass die Fehlererkennung/-korrektur aber keine weiteren Dateisystemfehler produziert, wenn nicht ECC eingesetzt wird, lässt sich zeigen. Ich nehme mal das Beispiel mit der Parität (ZFS, Btrfs hat noch keine RAID56-Unterstützung):

wir haben die Blöcke A, B und C, Blöcke A und B sind Datenblöcke, Block C ist Parität

a)
Block A wird jetzt in einen fehlerhaften Speicherbereich gelesen, so dass ein Bitfehler an der Stelle x passiert. Die berechnete Checksumme passt nicht zur gespeicherten, der Block wird vom Dateisystem als fehlerhaft erkannt. Aus den Blöcken B und C wird A neu berechnet und wieder an die Stelle im Speicher geschrieben, an dem er schon lag (in place). Das Dateisystem geht davon aus, den Fehler korrigiert zu haben und schreibt Block A zurück auf die Festplatte.
Jetzt ist durch die Fehlerkorrektur des Dateisystems der Fehler aus dem RAM auf die Platte propagiert worden, so weit so schlecht.

b)
Block A wird wieder in den fehlerhaften Speicher gelesen, jetzt etwas bit-verschoben. Der Bitfehler tritt jetzt nicht an Stelle x von Block A auf, sondern an Stelle y (y != x). Wir haben nun schon zwei fehlerhafte Stellen in Block A. Das Dateisystem erkennt wieder, dass die berechnete Checksumme nicht zur gespeichtern passt und versucht zu korrigieren. Aus den Blöcken B und C wird A rekonstruiert und an den Speicherbereich von Block A geschrieben. Durch den Bitfehler des Speichers ist Position y weiterhin defekt, Position x wurde aber korrigiert. Das Dateisystem geht wieder davon aus, alles ist korrekt, und schreibt Block A wieder auf die Platte. Jetzt ist Stelle y auf der Platte fehlerhaft.
Wir haben weiterhin einen Bitfehler in Block A auf der Platte, jetzt aber an anderer Stelle. Dieses Spiel können wir beliebig so treiben, es bleibt immer ein Bit fehlerhaft in Block A.

Jetzt gibt es prinzipiell zwei Optionen, was passieren kann. Fangen wir mit der angenehmeren an:

c)
Block A wird in den Speicher eingelesen, und zwar an eine Stelle, die korrekt funktioniert. Wir haben noch immer einen Bitfehler in Block A. Das Dateisystem erkennt dies beim Vergleich der Checksummen. Wiederum läuft die Korrektur an, aus Block B und C wird A neu berechnet, in den Speicher geschrieben und ist diesmal auch korrekt. Block A wird auf die Platte zurück geschrieben und der Fehler, der durch die Fehlerkorrektur des Dateisystems erst entstanden ist, ist behoben.

Kommen wir jetzt zur schlechten Option:

d)
Block B (oder C) wird in den Speicher an die fehlerhafte Stelle gelesen. Es gibt einen Bitfehler im Speicher, die Checksummen passen nicht und das Dateisystem versucht den Fehler zu korrigieren. Es will dafür Block B aus Block A und C rekonstruieren. Block A ist noch immer fehlerhaft. Das fällt beim Einlesen auf, die Checksummen passen auch hier nicht. Theoretisch müsste auch Block A korrigiert werden. Da jetzt aber die Redundanz nicht mehr vorhanden ist, ist dies unmöglich. Das Dateisystem muss den Korrekturversuch abbrechen, die Datei ist für das Dateisystem defekt.
Für das laufenden System heißt das, hier ist nichts mehr zu machen. Die Datei ist aber sehr wohl noch korrekt vorhanden und kann auf einem intakten System auch wieder gelesen und vollständig repariert werden. Denn auf der Platte ist nur Block A defekt. Steckt man die Platte jetzt in ein korrekt arbeitendes System und lässt die Fehlerkorrektur wieder laufen, muss Fall c) eintreten.

Der Fehler durch den RAM hat sich also nicht durch das Dateisystem ausgebreitet. Mehr noch, jeder durch das Dateisystem erkannte Fehler erzeugt eine Warnung. Dem Admin muss also sehr bald aufgehen, dass etwas an seinem Rechner überhaupt nicht stimmt. Ich würde sagen, der behauptete Nachteil von ZFS/Btrfs auf nicht ECC-Systemen existiert nicht. Im Gegenteil, anders als Dateisysteme ohne Fehlererkennung wird hier sogar der RAM-Fehler offen gelegt.
 
Das hängt davon ab ob es ein HW-RAID ist, dann hat der Controller i.d.R. die entsprechende Sicherung gegen RAM Fehler im Cache und bei normalen Filesystemen bleibt der Fehler erstmal unentdeckt, wie fast alle RAM Fehler, weshalb diese auch so unterschätzt werden: Da es keine Prüfsummen gibt, fällt der Fehler halt nur auf, wenn das Programm mit der Datei nichts anfangen kann oder vielleicht der Rechner abstürzt. Manchmal hat man auch Datenverlust, weil die Metadaten des Filesystems betroffen sind und schon wird eine Datei oder ein ganzer Ordner nicht mehr angezeigt, oder es werden Datein von der falsche Stelle gelesen, je nachdem welche Information durch den Fehler falsch geworden ist.

Was bei einem HW Raid passiert wenn der Controller zum spinnen anfängt, habe ich schon erlebt. Das gesamte RAID ist danach Müll. Und auch btw ECC Speicher kann nicht alle Softerrors korrigieren. Und was leider immer noch nicht einige verstanden haben, dass normales RAID keinerlei Kenntnis vom darunterliegenden Filesystem hat, es also im schlimmsten Fall die komplette MFT zerschiesst und alle Daten weg sind. Und genau das habe ich bei Hardware Raid + VMFS + NTFS auch schon erlebt, bei einer EMC Storage mit FC Anbindung im Enterprise Bereich.

Wenn hier jemand ein gekipptes Bit in den Dateien hat, dann dürfte es sehr, sehr wahrscheinlich ein RAM Fehler sein, denn bei Consumer HDDs liegt die Rate der unkorrigierbaren Bitfehler i.d.R. bei 1:10^14 Sektoren pro gelesenes Bit, also etwa einer pro 12TB und dann gibt es einen Lesefehler, also i.d.R. einen schwebenden Sektor und übliche Windowsprgramme sollen diesen Lesefehler anzeigen und den Vorgang abbrechen. Die Rate der unerkannten Bitfehler, also wenn die ECC den Fehler nicht erkennt und die falschen Daten als korrekt übernimmtelt, sind noch viel, viel seltener. Ansonsten könnte es noch ein Fehler in den internen Datenpfaden der Platte sein, bei einige Conusmer Platten gibt es dafür eine End-to-End Error Attribut in den S.M.A.R.T. Werten, andere sichern die Daten in den Datenpfaden nicht ab, Enterprise Platten machen das immer und auch entsprechend aufwendiger.

Das falsche Bit lag nicht in einer Datei sondern auf einer einzelnen Disk weil das RAID beim hochfahren ohne die eine Disk lief, weil sie nicht beim hochfahren vom System erkannt wurde und beim nächsten Boot war sie dann wieder drin. Logisch das der Inhalt der einen Platte dann nicht mehr zu den anderen passt. Dann kommt ein Scrub und alles ist wieder gut. Bei einem RAID muss die Disk wieder komplett neu durch rebuild konstruiert werden.

Was ZFS übrigens auch nicht macht ist den Cache für Checksums zu verwenden.

Wenn der Speicher beschädigt ist, hat man bei jedem FS Probleme und das der Scrub alle Daten killt müsste erstmal bewiesen werden.

Anstatt Foren Schnack hier mal was professionelleres:
http://research.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
Auf den Scrub gehen die aber leider auch nicht ein. Und warum die nur eine Disk verwenden, wissen wohl nur die.

Bei ZFS könnte man auch Chksums komplett deaktivieren. zfs set checksum=off
Aber Hilfreich ist das nicht.

Natürlich ist ECC Memory keine schlechte Idee aber das vorhandene Daten durch einen Scrub nachträglich korrumpiert werden, kann ich mir nicht vorstellen da diese Chksums nicht nur einmal sondern mehrfach abgelegt werden. Ob dazu mehrere Disks von Nöten sind, weiß ich nicht.
Wenn ZFS eine falsche Chksum erkennt wegen dem RAM dann wird es nochmal eine Prüfung machen bei der Kopie und laut hier:
http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/
auch keine Daten auf der Disk falsch korrigieren, selbst wenn beide mal die Chksum nicht stimmen, was doch extrem unwahrscheinlich ist.
 
Zuletzt bearbeitet:
Das meinst Du jetzt doch nicht etwa ernst oder ?
Ich weis ja nicht was Du als Router nennst, aber mein TP-Link kommt da locker drüber ???

Also ich hab gestern mal an einer neuen Fritzbox von 1&1 geschaut, da warens auch nur 5mb/s schreiben

--- Update ---

Wie ich oben beschrieben habe, passiert genau das eben nicht. ;)

Doch, ließ mal das PDF von mir. Aber die Probleme sind nicht so gigantisch wie die Leute es immer darstellen wollen.
Wenn ein RAM ernsthaft Probleme macht dann stürzt der komplette Rechner vorher ab.
 
Doch, ließ mal das PDF von mir. Aber die Probleme sind nicht so gigantisch wie die Leute es immer darstellen wollen.
Wenn ein RAM ernsthaft Probleme macht dann stürzt der komplette Rechner vorher ab.

Hab es jetzt nur kurz überflogen. Aber da steht doch vom Kontext her nix anderes, als ich hier auch skizziert habe. *noahnung*
 
Dass ZFS für ECC-RAM entworfen wurde, behauptest du immer wieder.
ZFS ist von Sun für Solaris entwickelt worden, also von einem Serverhersteller für ein Serverbetriebssystem und Server haben alle ECC RAM, wenn Du den Gegenbeweis findest wo die Entwickler oder Sun (jetzt Oracle) schreiben das auch für nicht ECC RAM Vorkehrungen eingebaut wurden, dann poste ihn doch. Ansonsten findest Du beim googlen zum Thema eher solche Berichte wo es die Leute auf die harte Tour lernen mussten.
Im Gegenteil, anders als Dateisysteme ohne Fehlererkennung wird hier sogar der RAM-Fehler offen gelegt.
Das stimmt, RAM Fehler können leichter erkannt werden, die Pools gehen aber trotzdem kaputt bzw. sind es meist, bevor das Problem erkannt wurde und darüber findest Du genug Berichte, deshalb werde ich darauf auch nicht weiter eingehen, es sind ja nicht meine Pools und nicht meine Daten.

Und was leider immer noch nicht einige verstanden haben, dass normales RAID keinerlei Kenntnis vom darunterliegenden Filesystem hat, es also im schlimmsten Fall die komplette MFT zerschiesst und alle Daten weg sind.
Das Schichtenmodell eines Speichersystems sollte man schon kennen, wenn man sich damit befasst, aber Du hast recht, vielen ist das nicht bekannt und ebenso nicht, dass ein RAID eben keine Backups ersetzt, wie so Beispiel auch deutlich zeigt.

Dann kommt ein Scrub und alles ist wieder gut.
Das sollte ein Resilvering gewesen sein.

Was ZFS übrigens auch nicht macht ist den Cache für Checksums zu verwenden.
..
Anstatt Foren Schnack hier mal was professionelleres:
http://research.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
Das steht da auch auf Seite 9:
Observation 1:
ZFS does not use the checksums in
the page cache along with the blocks to detect memory
corruptions.

Checksums are the first guard for detect-
ing data corruption in ZFS. However, when a block is
already in the page cache, ZFS implicitly assumes that it
is protected against corruptions.
Das sollte hoffentlich auch den Zweifel ausräumen, ob ZFS nun auf ECC-RAM ausgelegt ist oder nicht, denn wenn es nicht erwarten würde auf ECC RAM zu laufen, wäre auch eine Checksumme über die RAM Inhalten implementiert worden, worauf aber verzichtet wurden, weil man diesen Teil von der HW erwartet.

Der entscheidende Punkt dürfte der auf Seite 11 sein, der auch zum Poolverlust führt:
In summary, ZFS fails to detect and recover from
many corruptions. Checksums in the page cache are not
used to protect the integrity of blocks. Therefore, bad
data blocks are returned to the user or written to disk.
Moreover, corrupted metadata blocks are accessed by
ZFS and lead to operation failure and system crashes.
Die Metadaten sind eben bei jedem Filesystem kritisch und ZFS legt sie auch noch komprimiert ab, muss sie also immer wieder ins RAM entpacken, weshalb es ja auch sehr internsiv das RAM nutzt und mehr RAM als andere Filesysteme belegt, womit eben auch das Risiko steigt von RAM Fehlern betroffen zu werden.

Natürlich ist ECC Memory keine schlechte Idee
So kann man es auch ausdrücken, aber ich will hier keine weitere Diskussion darüber führen, es sind ja nicht meine Daten und es ist nicht meine HW. Ich wollte nur auf das Risiko hinweisen und die Entscheidung muss am Ende jeder selbst fällen, er sollte aber um das Risko wissen und keiner sollte so tun oder sich der Illusion hingeben als könnte ZFS für sich alleine auch ohne ECC RAM die Silent Data Corruption vermeiden, denn das ist ja der Fokus bei ZFS und deshalb auch die Checksummen, alleine wegen der RAID Funktion werden es wohl die wenigstens User einsetzen.
 
Zuletzt bearbeitet:
Das sollte ein Resilvering gewesen sein.

Ja natürlich, kommt aber aufs selbe

Das steht da auch auf Seite 9: Das sollte hoffentlich auch den Zweifel ausräumen, ob ZFS nun auf ECC-RAM ausgelegt ist oder nicht, denn wenn es nicht erwarten würde auf ECC RAM zu laufen, wäre auch eine Checksumme über die RAM Inhalten implementiert worden, worauf aber verzichtet wurden, weil man diesen Teil von der HW erwartet.

Der entscheidende Punkt dürfte der auf Seite 11 sein, der auch zum Poolverlust führt: Die Metadaten sind eben bei jedem Filesystem kritisch und ZFS legt sie auch noch komprimiert ab, muss sie also immer wieder ins RAM entpacken, weshalb es ja auch sehr internsiv das RAM nutzt und mehr RAM als andere Filesysteme belegt, womit eben auch das Risiko steigt von RAM Fehlern betroffen zu werden.

So kann man es auch ausdrücken, aber ich will hier keine weitere Diskussion darüber führen, es sind ja nicht meine Daten und es ist nicht meine HW. Ich wollte nur auf das Risiko hinweisen und die Entscheidung muss am Ende jeder selbst fällen, er sollte aber um das Risko wissen und keiner sollte so tun oder sich der Illusion hingeben als könnte ZFS für sich alleine auch ohne ECC RAM die Silent Data Corruption vermeiden, denn das ist ja der Fokus bei ZFS und deshalb auch die Checksummen, alleine wegen der RAID Funktion werden es wohl die wenigstens User einsetzen.

Da steht sehr viel, aber eben auch nicht das ein Scrub das gesamte Dateisystem beschädigt. Von Poolverlust lese ich da auch nichts. Das aus dem Cache keine Checksums benutzt werden habe ich oben schon erwähnt und steht auch in dem Artikel.

Und wenn neue Files in ZFS geschrieben werden und wenn dabei vorher Memoryfehler auftauchen, dann ist es klar das da nichts gescheites bei rauskommt. Genauso wenn Dateien gelesen werden können Fehler auftreten aber afaik werden dabei nicht die Daten auf der Disk nachträglich verändert.

Im Heimbereich gibts nunmal leider keine stromsparende Hardware für ECC Speicher die man auf 10W bringt. Aber das heisst noch lange nicht das ZFS dort schlechter wäre als andere FS, im Gegenteil. Wenn man regelmäßige Scrubs macht und dabei unkorrigierbare Fehler auftauchen dann weiß man wenigstens bescheid das etwas an der Hardware nicht stimmt.
 
Zuletzt bearbeitet:
Zusammengefasst: Ein Haufen falscher Schlussfolgerungen...

Um es mal auf den Punkt zu bringen, ZFS (und ähnliche Dateisysteme) wurde entwickelt, um Fehler auf Block Device Ebene abzufassen. Das macht es im Rahmen seiner Anforderungen. Es wurde nicht entwickelt, um Fehler im RAM zu behandeln. Das tut es auch nicht. Es kann aber dazu beitragen, solche Fehler zu erkennen.
Hier wurde die Behauptung aufgestellt, dass ZFS Fehler im RAM mehr bzw. sogar wesentlich mehr als herkömmliche Dateisysteme auf permanente Speichersysteme (HDD) ausweitet. Dafür wurde bislang kein Beleg erbracht. Es wurde immer nur wieder darauf verwiesen, ZFS ist ja für Server mit ECC entwickelt worden. Gegenteilige Ausführung wurde ignoriert.

Klingt für mich sehr nach den alten Werbeveranstaltungen, wo teuer mit noch mehr teuer verkauft werden sollte. Und macht natürlich auch Eindruck auf all die, die von der Materie keine Ahnung haben.
 
Zuletzt bearbeitet:
Das meinst Du jetzt doch nicht etwa ernst oder ?
Ich weis ja nicht was Du als Router nennst, aber mein TP-Link kommt da locker drüber ???
Scheint bei TP-Link eine neue Entwicklung zu sein :D, schnelle USB-Ports zu bauen. Da sollten wohl die anderen mal nachziehen. Früher was das halt nicht so...
http://www.winfuture-forum.de/index.php?showtopic=183749&st=0&p=1589386&#entry1589386

@Holt&Co.
Was habt ihr jetzt seitenlang für Paras mit ZFS? :) Ich kenn nicht einen NAs was ZFS nutzt und ich kenne auch keinen der bei selfmadeNAS es nutzt (und da kenn ich schon einige). Gladiatorenkämpfe der Ungebräunten? ;)

@Onkel Homie
Ja es ist ne Weile mieser geworden teilweise. Faustregel ist eigentlich 1x 2 Ghz oder 2x 1.2 Ghz. Drunter sollte man auch bei nur 1-2 bays nicht gehen.
Qnap schnallt es langsam. Die TS-231 kostet 208€ und schiebt mit "Freescale ARM Cortex-A9" 2x 1.2 Ghz an bei 512MB. Das reicht. Die 131 genauzso.

Was Synology veranstaltet weiß ich nicht. DS215j mit 2x 800 für 156€. Das ist ein Witz sowas. Eine DS214+ hat 2x 1.33 Ghz, frisst aber auch gleich 28W aus der Steckdose. Und kostet auch noch 292€. An sich auch ein Witz.

DS115j (1 Platte) hat 1x 800 Mhz und 256 MB für ~142€. Qnap TS-131 hat auch 2x 1.2 Ghz CortexA9, 512 MB und kostet 157€.

Früher hat Synology besser Firmwares gehabt. Das ist seit 4.1 bei Qnap nicht mehr der Fall. Auch wenn man da noch gucken muß welche Unterversion man nimmt ;) Findet man ber schnell heraus.

Wenn man sich also so eine lahme Gurke holt ist es kein Wunder, daß man sich dann fragt was das mit dem FertigNAS nun soll.
 
PuckPoltergeist, Du musst wohl wirklich erst Deinen Pool verlieren und ich wünsche es Dir nach der Stuhrköpfigkeit jetzt auch von Herzen und möglichst bald, nur so wirst Du aufhören so einen Mist weiter zu verbreiten und andere zu dem gleichen Risiko zu verleiten. Außerdem verkaufe ich hier (oder anderswo) niemandem etwas, daher ist das Thema für mich entgültig durch.

HalbeHälfte, fertige Consumer NAS unterstützen ZFS nicht, die haben ja auch kein ECC RAM, sowieso wenig RAM und schache CPUs, deshalb kommt meist der Vorschlag einen alten Rechner dafür zu nutzen oder sich selbst was mit günstiger HW zu bauen und dann ebnen auch meist ZFS in Spiel (FreeNAS nutzt das gewöhnlich), daher die Diskussion. Das ging ja schon in Post #4 los. Im Grunde sogar schon in Post #2. Ich will auch niemand überzeugen warum das so ist, wer es wissen will gut und wer es nicht glaubt oder meint es werde schon gutgehen, von mir aus auch gut, es sind ja nicht meine Daten und gewarnt habe ich, mehr kann ich nicht tun.
 
Zuletzt bearbeitet:
@HalbeHälfte:
Ich halte von den ganzen ARM&Marvel Kisten nix.
Teils zu lahm, teils schlechte Erfahrungen und wenn man auch nur mal Java benötigt muss das Ding X86 kompatibel sein.

Ob jetzt Qnap oder Synology, sind beide ganz okay meine ich.
Bei mir haben im (erweiterten) Bekanntenkreis wenn dann alle von Qnap zu Synology gewechselt und sind deutlich zufriedener *noahnung*
 
Ich selbst habe eine AM1-Kiste im Silverstone DS380 mit 8 WD Red in ZFS (6x in RAID 6 und 2x in RAID 1)

Da ja AM1 kein ECC-RAM nimmt, kann ich euch ja irgendwann mal berichten, falls sich defekter RAM und Scrub zum Scrub of Death vereinen. ;D
 
@bschicht
:)

@Onkel
Ist aber imho auch nicht gewöhnlich, so ein Nutzungsprofil. Den meisten Nicht-cracks geht es nur um Dateizugriff und ggbf. DLNA. Die benötgte Leistung sollte man halt abschätzen können.
Wenn man es nicht kann, erledigt sich das von alleine, weil dann benötigt man es auch nicht, da man keine Ahnung davon hat :) Dann gelten einfach nur die Regeln die ich erwähnt habe (wegen Leistungsabschätzung).

Wie gesagt, man hing bei Qnap mit der Softquali hinterher. Ist jetzt nicht mehr und den Marvel/ARM-Markt macht aktuell Synology selbst kaputt, weil sie mit noch gutem Namen vergleichbar preislich attraktive Geräte nur in Schnarchlahm anbieten. Man muß für gleiche Leistung teils ~35% mehr bezahlen.
 
Zur ZFS-Diskussion: Ist doch doch im Prinzip alles Wurst: Für praktisch alle Datei-/RAID-Systeme gilt:

1. Wird Müll an der falschen Stelle geschrieben, sind im schlimmsten Fall alle Daten Weg.
2. Dateisysteme wie ZFS sind definitiv derzeit nicht gegen RAM-Fehler geschützt (durch zusätzliche Prüfungen, etc. im Speicher).
3. RAM-Fehler treten statistisch relativ Häufig auf.
4. Wem seine Daten wichtig sind, benutzt ECC-RAM um wenigstens vor Einzelbit-Fehlern sicher zu sein.
 
Zur ZFS-Diskussion: Ist doch doch im Prinzip alles Wurst: Für praktisch alle Datei-/RAID-Systeme gilt:

1. Wird Müll an der falschen Stelle geschrieben, sind im schlimmsten Fall alle Daten Weg.
2. Dateisysteme wie ZFS sind definitiv derzeit nicht gegen RAM-Fehler geschützt (durch zusätzliche Prüfungen, etc. im Speicher).
3. RAM-Fehler treten statistisch relativ Häufig auf.
4. Wem seine Daten wichtig sind, benutzt ECC-RAM um wenigstens vor Einzelbit-Fehlern sicher zu sein.
5. Wenn man ZFS einsetzt, muss man ECC-RAM nutzen. Sonst verliert man nämlich seinen Pool, weil ZFS den RAM exzessiv nutzt. *rofl*
 
Zurück
Oben Unten