App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Flex-RAID anstatt RAID5?
- Ersteller Unlimited
- Erstellt am
Unlimited
Commodore Special
- Mitglied seit
- 10.07.2007
- Beiträge
- 384
- Renomée
- 5
- Mein Laptop
- Toshiba Portege
- Prozessor
- Intel C2D E4300 undervolted @ 2,4GHz
- Mainboard
- Gigabyte GA-P35C-DS3R
- Kühlung
- Wasserkühlung, passiv
- Speicher
- 2x4GB DDR3 1600
- Grafikprozessor
- GF 440GT OEM
- Display
- Dell U2412M
- HDD
- Systemplatte OCZ Agility3 120GB
- Soundkarte
- onboard
- Gehäuse
- Avance B031 Titan
- Netzteil
- Arctic Cooling Artic Fusion 550R
- Betriebssystem
- Win7 Prof
- Webbrowser
- Mozilla FF + Opera
- Verschiedenes
- Cacheplatte OCZ Vertex 2 60GB old rev. , Datenplatte SnapRAID 2x2TB+2x1TB , Backupplatte Samsung 204UI
Generell enstand im Privatbereich halt der Irrglaube, dass RAID für Sicherung der Daten eingeführt wurde ... was Quatsch ist, seit jeher war der Anspruch unterbrechungsfreie Verfügbarkeit und mit etwas Abstand an zweiter Stelle die Performance. Die Verwendung in Backupstrategien beschränkt sich dann auf getrennte Systeme, die sich dem Workload und Zugriff der Nutzer entziehen.
Ja, wobei die Absicherung gegen Hardwaredefekt einer Platte auch nicht unwichtig ist.
Jeder definiert seine Ansprüche halt anders.
Bei mir wars damals im RAID5 folgende Reihenfolge, so wie wohl bei der Mehrheit der Nutzer:
1. Absicherung gegen Defekt
2. Performance
dann erst mit gaaanz großem Abstand:
3. unterbrechungsfreie Verfügbarkeit
Klar, oder?
3. ist in Produktivumgebungen wichtig, nicht aber bei Privatnutzern.
Wirkliche Performance gabs damals ja eigentlich auch nur via RAID0.
Das MatrixRAID war an dieser Front richtig innovativ, denn es hatte ein geniales Alleinstellungsmerkmal: es konnte RAID5 und RAID0 auf dem selben RAID-Verbund fahren.
War genial i.d. Theorie:
Mit 4 Platten ein RAID5 erstellen und auf jeder Platte die 20 schnellsten GB fürs RAID0 abzwacken, ergab 80GB Systemspeicher mit für damalige Verhältnisse superschnellen 300-400MB/s, ohne dass man dafür nochmals 4 Platten anschaffen und den Großteil des Platzes verschwenden musste.
Für die Performance brauche ich heute aber kein RAID5 mehr, weil es lächerlich ist im Vergleich zu meinem SSD-Cache.
Also bleibt nur Punkt 1, der fürs RAID5 spricht.
Backup wurde/wird natürlich extern gemacht, wobei ich mir den Luxus erlaube die Backupfrequenz sehr stark herunter zu fahren.
Zuletzt bearbeitet:
yourgreatestfear
Grand Admiral Special
- Mitglied seit
- 17.08.2003
- Beiträge
- 5.193
- Renomée
- 142
- Standort
- Dresden - Germany
- Mein Laptop
- Dell Latitude XT2 (Samsung SSD 128GB-RBB)
- Prozessor
- Intel Q9550 2,83 @ 0,99 - 3,2
- Mainboard
- Asus P5Q-Deluxe
- Kühlung
- Coolermaster GeminII S
- Speicher
- 4 x 2GB DDR2 PC800 CL4 Corsair XMS2 DHX
- Grafikprozessor
- Asus GTX 960 Turbo 2G
- Display
- 30" Dell 3008WFP @2560x1600 & 22"LG @1650x1050
- SSD
- Crucial MX200 250 GB
- HDD
- 2x WD Velociraptor 300GB @ RAID 0 Intelcontroller
- Optisches Laufwerk
- Samsung DVD-RW/DL
- Soundkarte
- Creative X-Fi Titanium PCIe
- Gehäuse
- Zalman HD 160 Plus schwarz
- Netzteil
- BeQuiet 400W Pure Power L8
- Betriebssystem
- Win10 64Bit H + diverse in VMware
- Webbrowser
- FF
jetzt musst mir in Deiner Logik nur noch erklären, wieso Deine Absicherung gegen Defekt nicht gleichbedeutend mit dem Anspruch an unterbrechungsfreier Verfügbarkeit ist.
Unlimited
Commodore Special
- Mitglied seit
- 10.07.2007
- Beiträge
- 384
- Renomée
- 5
- Mein Laptop
- Toshiba Portege
- Prozessor
- Intel C2D E4300 undervolted @ 2,4GHz
- Mainboard
- Gigabyte GA-P35C-DS3R
- Kühlung
- Wasserkühlung, passiv
- Speicher
- 2x4GB DDR3 1600
- Grafikprozessor
- GF 440GT OEM
- Display
- Dell U2412M
- HDD
- Systemplatte OCZ Agility3 120GB
- Soundkarte
- onboard
- Gehäuse
- Avance B031 Titan
- Netzteil
- Arctic Cooling Artic Fusion 550R
- Betriebssystem
- Win7 Prof
- Webbrowser
- Mozilla FF + Opera
- Verschiedenes
- Cacheplatte OCZ Vertex 2 60GB old rev. , Datenplatte SnapRAID 2x2TB+2x1TB , Backupplatte Samsung 204UI
jetzt musst mir in Deiner Logik nur noch erklären, wieso Deine Absicherung gegen Defekt nicht gleichbedeutend mit dem Anspruch an unterbrechungsfreier Verfügbarkeit ist.
Unterbrechungsfreie Verfügbarkeit ist mir völlig wurscht, damals gabs halt Absicherung gegen ein HDD-Defekt im RAID5 nur in Kombi mit unterbrechungsfreier Verfügbarkeit.
Aus heutiger Sicht (SSDs) und aus der Sicht eines Homeusers kann man sagen:
"Unterbrechungsfreie Verfügbarkeit" auf die Art, wie RAID5 sie bieten kann, bringt sehr viele Nachteile mit sich und ist im RAID5 dadurch leider ein notweniges Übel.
"Performance" auf die Art, wie RAID5 sie bieten kann, bringt sehr viele Nachteile mit sich und ist im RAID5 dadurch leider ein notwendiges Übel.
Heute geht es zum Glück auch wieder ohne die mit "unterbrechungsfreier Verfügbarkeit" und "Performance" einhergehenden Nachteile, und ich bevorzuge dies.
Heute bekomme ich nur das was ich will: Absicherung gegen Defekt eines Laufwerks.
Die Lösung nennt sich SnapshotRAID, verstehe es endlich...
Die Vorteile von SnapshotRAIDs FÜR HOMEUSER!!! ggü. Mirrors und RAID5 allgemein sind dramatisch...
Abgesehen davon, Privatnutzer brauchen einfach keine unterbrechungsfreie Verfügbarkeit.
Punkt.
Unterbrechungsfreie Verfügbarkeit führt im RAID5 zu um mindestens den Faktor 300% erhöhter Ausfallwahrscheinlichkeit durch Abnutzung der Platten, Stromverbrauch, Lärm, Wärme im PC, alle Platten müssen permanent zugleich laufen, Platzverschwendung, hohe Investkosten durch Anschaffung vieler großer Platten zugleich, deren Speicher man erst später benötigt, wenn er billiger zu kaufen wäre, RAID5 bringt selber zusätzliche erhebliche systemimmanente Risiken ins System, RAID5 ist sein größter Feind selber, sprich statistisch gehen im RAID5 die meisten Daten verloren wegen Problemen, die erst durch RAID5 geschaffen wurden, blablabla, etc. steht alles weiter vorne.
Alle Nachteile von RAID5 das sind zugleich die Vorteile von SnapRAID!
Daraus folgt logisch, dass ich SnapRAID bevorzuge ggü. RAID5... zugleich geht aus deiner Frage hervor, dass du eben die deiner Ansicht nach "geringen" Vorteile von SnapshotRAID irgendwie doch nicht verstanden hast, weil sonst würdest du obige Frage gar nicht erst fragen.
Denn SnapshotRAID ist eben nichts anderes, als "Absicherung gegen Defekt"
ohne "unterbrechungsfreie Verfügbarkeit" mit deren Nachteilen und als Bonus auch noch
ohne "Performance" mit deren Nachteilen.
Somit widersprichst du dir selber und beantwortest du es ja indirekt selber so, dass du SnapshotRAID als bessere Alternative für Privatanwender siehst mit folgendem Satz:
"Generell enstand im Privatbereich halt der Irrglaube, dass RAID für Sicherung der Daten eingeführt wurde ... was Quatsch ist, seit jeher war der Anspruch unterbrechungsfreie Verfügbarkeit und mit etwas Abstand an zweiter Stelle die Performance."
Und da stimme ich dir auch zu!
SnapshotRAID wurde hauptsächlich zur Sicherung der Daten vor dem Ausfall eines Laufwerks eingeführt.
Indem man die Daten "vor dem Ausfall eines Laufwerks" schützt, hat man jedoch bereits die mit Abstand schlimmste nicht-menschliche Datenverlustwahrscheinlichkeit aus dem System genommen und kann sich tatsächlich bzgl. Backups eher zurücklehnen, als ohne SnapshotRAID.
Zuletzt bearbeitet:
JKuehl
Grand Admiral Special
- Mitglied seit
- 22.06.2003
- Beiträge
- 7.903
- Renomée
- 145
- Standort
- Stockholm, Schweden
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- POEM, SIMAP
- Lieblingsprojekt
- SIMAP, POEM
- Meine Systeme
- Q6600
- BOINC-Statistiken
- Folding@Home-Statistiken
- Prozessor
- Ryzen-3700x
- Mainboard
- Asus B350 Prime Plus
- Kühlung
- Fractal Design Celsius 240
- Speicher
- 48 GB Corsair LPX 3000
- Grafikprozessor
- 1080ti
- Display
- 28" Samsung 3840x2160
- SSD
- Samsung Evo 960 500Gb
- Soundkarte
- Creative X-Fi Titanium PCIe
- Netzteil
- Be Quiet Dark Power 650
- Betriebssystem
- Windows 10 64 Bit
jup, ZFS verwendet bewusst striping und kennt kein JBODartiges verwenden von Plattenverbünden... Redundanz durch einen Spiegel oder eine Parität ist halt genug, wenn nicht wendet man höhere Level an. Die Paranoia gegenüber multiplen Plattenversagen ist nicht mehr ganz vernünftig in der heutigen Zeit, vor allem im Privatbereich und mit regulären Backupstrategien.
Das ist so nicht richtig, denn genau der Otto-Normalverbraucher hat alles auf einem Array und eben KEINE Backupstrategie.
Ich habe das vernünftig durchdacht und eine Backupstrategie nach Wichtigkeit der Daten bei mir implementiert. Auf den Festplatten befinden sich nur Daten der untersten Stufe sowie zusätzliche Backups der darüberliegenden Schichten.
Ich habe festgestellt dass mit abnehmender Wichtigkeit die Datenmengen auch immer größer werden (z.B. wichtigste Dokumente rund 100 MB, nächste Stufe sind wichtige Daten mit rund 2GB, danach folgen RAW-Fotos und der ganze Rest mit 1.5 TB)
Auf der letzten Stufe sind dann rund 10 TB Daten, die ich nicht separat sichern werde weil es einfach zu teuer ist - bei denen es dennoch schade wäre sie zu verlieren. Alle Daten hier sind wiederbeschaffbar, aber eben mit einem zeitlichen Aufwand. Um diesen zu begrenzen, und weil eine separate Sicherung zu teuer wäre setze ich auf snapraid.
Spinup / Spindown ist übrigens kein Problem. Rund 10.000 in 3 Jahren sind bei allen eingesetzten Platten kein Problem (alle mit mindestens 200.000 spezifiziert).
Der Stromverbrauch ist dann auch noch ausschlaggebend.
Unlimited
Commodore Special
- Mitglied seit
- 10.07.2007
- Beiträge
- 384
- Renomée
- 5
- Mein Laptop
- Toshiba Portege
- Prozessor
- Intel C2D E4300 undervolted @ 2,4GHz
- Mainboard
- Gigabyte GA-P35C-DS3R
- Kühlung
- Wasserkühlung, passiv
- Speicher
- 2x4GB DDR3 1600
- Grafikprozessor
- GF 440GT OEM
- Display
- Dell U2412M
- HDD
- Systemplatte OCZ Agility3 120GB
- Soundkarte
- onboard
- Gehäuse
- Avance B031 Titan
- Netzteil
- Arctic Cooling Artic Fusion 550R
- Betriebssystem
- Win7 Prof
- Webbrowser
- Mozilla FF + Opera
- Verschiedenes
- Cacheplatte OCZ Vertex 2 60GB old rev. , Datenplatte SnapRAID 2x2TB+2x1TB , Backupplatte Samsung 204UI
Das ist so nicht richtig, denn genau der Otto-Normalverbraucher hat alles auf einem Array und eben KEINE Backupstrategie.
Ich habe das vernünftig durchdacht und eine Backupstrategie nach Wichtigkeit der Daten bei mir implementiert. Auf den Festplatten befinden sich nur Daten der untersten Stufe sowie zusätzliche Backups der darüberliegenden Schichten.
Ich habe festgestellt dass mit abnehmender Wichtigkeit die Datenmengen auch immer größer werden (z.B. wichtigste Dokumente rund 100 MB, nächste Stufe sind wichtige Daten mit rund 2GB, danach folgen RAW-Fotos und der ganze Rest mit 1.5 TB)
Auf der letzten Stufe sind dann rund 10 TB Daten, die ich nicht separat sichern werde weil es einfach zu teuer ist - bei denen es dennoch schade wäre sie zu verlieren. Alle Daten hier sind wiederbeschaffbar, aber eben mit einem zeitlichen Aufwand. Um diesen zu begrenzen, und weil eine separate Sicherung zu teuer wäre setze ich auf snapraid.
Spinup / Spindown ist übrigens kein Problem. Rund 10.000 in 3 Jahren sind bei allen eingesetzten Platten kein Problem (alle mit mindestens 200.000 spezifiziert).
Der Stromverbrauch ist dann auch noch ausschlaggebend.
Alles sehr gut und richtig, wobei das alles auch bereits auf den Seiten vorher ausführlich erläutert wird.
Ich meine es wirklich nicht böse, aber es wäre gut, wenn der Herr ygf sichs halt einfach mal durchlesen und verstehen würde, anstatt hier dauernd in aggressivem / provokantem Ton überflüssige Fragen und Einwände zu spammen, die längst beantwortet sind.
So wird der ganze Thread nur unnötig verwässert durch Wiederholungen.
Fragen von ygf bitte künftig gerne auch per BM direkt an mich.
ghostadmin
Grand Admiral Special
Ich sag immer so, wenn man kein Backup macht dann sind die Daten auch nicht wichtig.
Und wenn Otto Normalverbraucher kein Backup macht dann meistens weil er denkt das RAID dies ersetzt.
Und wenn Otto Normalverbraucher kein Backup macht dann meistens weil er denkt das RAID dies ersetzt.
Unlimited
Commodore Special
- Mitglied seit
- 10.07.2007
- Beiträge
- 384
- Renomée
- 5
- Mein Laptop
- Toshiba Portege
- Prozessor
- Intel C2D E4300 undervolted @ 2,4GHz
- Mainboard
- Gigabyte GA-P35C-DS3R
- Kühlung
- Wasserkühlung, passiv
- Speicher
- 2x4GB DDR3 1600
- Grafikprozessor
- GF 440GT OEM
- Display
- Dell U2412M
- HDD
- Systemplatte OCZ Agility3 120GB
- Soundkarte
- onboard
- Gehäuse
- Avance B031 Titan
- Netzteil
- Arctic Cooling Artic Fusion 550R
- Betriebssystem
- Win7 Prof
- Webbrowser
- Mozilla FF + Opera
- Verschiedenes
- Cacheplatte OCZ Vertex 2 60GB old rev. , Datenplatte SnapRAID 2x2TB+2x1TB , Backupplatte Samsung 204UI
Ich sag immer so, wenn man kein Backup macht dann sind die Daten auch nicht wichtig.
Und wenn Otto Normalverbraucher kein Backup macht dann meistens weil er denkt das RAID dies ersetzt.
Ja es ist oft einfach nur das Unwissen... leider... so wars bei mir auch vor vielen jahren, doch aus Schaden wird man manchmal klug
ghostadmin
Grand Admiral Special
Hab ich gestern erst wieder bei einer Schule gesehen. Da werden Enterprise Produkte wie Vmware ESX eingesetzt aber es gibt keinerlei Backup.
Das erklärt dann einigesso wars bei mir auch vor vielen jahren, doch aus Schaden wird man manchmal klug
Trotzdem gilt auch für SnapRAID, dass RAIDs keine Backups ersetzen! Eben weil sie gegen viele Risiko denen Daten ausgesetzt sind nicht schützen können, ja ich weiß das nur andere User dumme Fehler machen die sie ihre Daten kosten und man eben doch noch Lotto spielt welche Daten es im Zweifel trifft, sollte es zu dem Ausfall von einer Platte zu viel kommen, bevor die zuvor ausgefallenen ersetzt wurden, was ja auch zuerst das Erkennen des Ausfalls bedingt.
ghostadmin
Grand Admiral Special
Wenn der Controller spinnt oder die HDDs wegen Überspannung sterben bringt FlexRAID auch herzlich wenig.
Bei ersterem sollte ZFS aber nicht so empfindlich sein bei vorhandenen Daten.
Bei ersterem sollte ZFS aber nicht so empfindlich sein bei vorhandenen Daten.
ZFS ist sehr empfindlich auf RAM Fehler, denn es hält viele und große Metadatenstrukturen lange im RAM und ist damit entsprechenden Risiken ausgesetzt, zumal es seine Datenstrukturen im RAM anders als auf den Platten eben nicht selbst mit Prüfsummen schützt. Aber das ist ja auch für den Servereinsatz entwickelt worden und da gibt es immer ECC, die HW schützt also vor RAM Fehlern.
tomturbo
Technische Administration, Dinosaurier
- Mitglied seit
- 30.11.2005
- Beiträge
- 9.455
- Renomée
- 665
- Standort
- Österreich
- Aktuelle Projekte
- Universe@HOME, Asteroids@HOME
- Lieblingsprojekt
- SETI@HOME
- Meine Systeme
- Xeon E3-1245V6; Raspberry Pi 4; Ryzen 1700X; EPIC 7351
- BOINC-Statistiken
- Mein Laptop
- Microsoft Surface Pro 4
- Prozessor
- R7 5800X
- Mainboard
- Asus ROG STRIX B550-A GAMING
- Kühlung
- Alpenfön Ben Nevis Rev B
- Speicher
- 2x32GB Mushkin, D464GB 3200-22 Essentials
- Grafikprozessor
- Sapphire Radeon RX 460 2GB
- Display
- BenQ PD3220U, 31.5" 4K
- SSD
- 1x HP SSD EX950 1TB, 1x SAMSUNG SSD 830 Series 256 GB, 1x Crucial_CT256MX100SSD1
- HDD
- Toshiba X300 5TB
- Optisches Laufwerk
- Samsung Brenner
- Soundkarte
- onboard
- Gehäuse
- Fractal Design Define R4
- Netzteil
- XFX 550W
- Tastatur
- Trust ASTA mechanical
- Maus
- irgend eine silent Maus
- Betriebssystem
- Arch Linux, Windows VM
- Webbrowser
- Firefox + Chromium + Konqueror
- Internetanbindung
-
▼300
▲50
Das ist in der Tat der größte Nachteil von ZFS.
Daher ist auch meiner Meinung nach ein Block RAID auf solchen Maschinen sinnvoller, da es einfach unempfindlicher im Betrieb ist.
Scrubbing ist allerdings auch dort zu empfehlen.
Daher ist auch meiner Meinung nach ein Block RAID auf solchen Maschinen sinnvoller, da es einfach unempfindlicher im Betrieb ist.
Scrubbing ist allerdings auch dort zu empfehlen.
yourgreatestfear
Grand Admiral Special
- Mitglied seit
- 17.08.2003
- Beiträge
- 5.193
- Renomée
- 142
- Standort
- Dresden - Germany
- Mein Laptop
- Dell Latitude XT2 (Samsung SSD 128GB-RBB)
- Prozessor
- Intel Q9550 2,83 @ 0,99 - 3,2
- Mainboard
- Asus P5Q-Deluxe
- Kühlung
- Coolermaster GeminII S
- Speicher
- 4 x 2GB DDR2 PC800 CL4 Corsair XMS2 DHX
- Grafikprozessor
- Asus GTX 960 Turbo 2G
- Display
- 30" Dell 3008WFP @2560x1600 & 22"LG @1650x1050
- SSD
- Crucial MX200 250 GB
- HDD
- 2x WD Velociraptor 300GB @ RAID 0 Intelcontroller
- Optisches Laufwerk
- Samsung DVD-RW/DL
- Soundkarte
- Creative X-Fi Titanium PCIe
- Gehäuse
- Zalman HD 160 Plus schwarz
- Netzteil
- BeQuiet 400W Pure Power L8
- Betriebssystem
- Win10 64Bit H + diverse in VMware
- Webbrowser
- FF
ZFS ist sehr empfindlich auf RAM Fehler, denn es hält viele und große Metadatenstrukturen lange im RAM und ist damit entsprechenden Risiken ausgesetzt, zumal es seine Datenstrukturen im RAM anders als auf den Platten eben nicht selbst mit Prüfsummen schützt. Aber das ist ja auch für den Servereinsatz entwickelt worden und da gibt es immer ECC, die HW schützt also vor RAM Fehlern.
Und schon wieder so ein Gerücht was sich ohne Rückhalt in der Realität verbreitet hat und jeglicher Logik widerspricht!
Lest euch mal das durch hier LINK und kloppt endlich mal diese irrealistischen Schnappsideen in den Abfalleimer!
prinzipiell verlangt ZFS etwas mehr RAM, weils ARC nutzt. Das hat aber keine Relevanz für die Datenintegrität, sondern nur für die Performance der Lese-/Schreibvorgänge. Dazu müsste man aber halt verstehen was ARC macht und wieso Fehler darin nicht zu Datenkorruption führen können.
PS: Manche hier sollten generell mal ihre Vorstellungen zu den verschiedenen RAID/FS-Implementierungen von Altlasten der Vergangenheit und rückhaltlosen Vermutungen befreien.
PS2: Auch falsch, dass die Cacheinhalte nicht durch Prüfsummen geschützt sind, Read/write in ARC caches sind äquivalent zu Direktzugriffen bzgl. der Datenintegrität ... wers nicht glaubt kann sich Suns Analytics zu den verschiedenen Storagesystemen mal durchblättern und wird mitbekommen wie ZFS auf Cachefehler, identifiziert durch checksums oder I/Oerrors, reagiert und das es dann immer zum Fallback kommt.
bsp für so ne storage analyse: http://docs.oracle.com/cd/E22471_01/html/820-4167/ch6.html
Zuletzt bearbeitet:
ghostadmin
Grand Admiral Special
Wenn der RAM spinnt ist jedes Dateisystem in Gefahr
Und die Checksums sind ja grade das gute an ZFS weil es die Files sieht und nicht nur Blocks.
Und die Checksums sind ja grade das gute an ZFS weil es die Files sieht und nicht nur Blocks.
Und verbreitest das Gegengerücht ohne zu verstehen wo das Problem liegt.Und schon wieder so ein Gerücht was sich ohne Rückhalt in der Realität verbreitet hat und jeglicher Logik widerspricht!
Denn auch hier wurde nicht verstanden, wo wirklich das Problem ist, denn da geht es um die Korruption der Nutzdaten, die schützt ZFS ja mit seinen Prüfsummen. Es geht aber um die Korruption der Metadaten des Filesystems und die schützt ZFS eben gerade nicht, weil es sich da auf die Serverhardware verlässt, für die es ja entwickelt wurde. Da es auch besonders umfangreich seine Metadaten ins RAM lagert, ist die Gefahr eben auch höher als bei anderen Filesystemen und dann verliert man auch mal den ganze Pool.Lest euch mal das durch hier LINK und kloppt endlich mal diese irrealistischen Schnappsideen in den Abfalleimer!
Um die geht es auch nicht, das sind nicht die Metadaten des Filesystems und Du solltest erst einmal verstehen, was denn Metadaten eines Filesystems sind, bevor Du hier weiter Unsinn schreibst weil Du alles verwechselst. Suche mal selbst nach einem Beleg wo angegeben wird, ob ZFS seine Metadaten im RAM schützt, dann solltest Du mehr lernen als wenn ich Dir ein paar Links vorlege.Auch falsch, dass die Cacheinhalte nicht durch Prüfsummen geschützt sind
yourgreatestfear
Grand Admiral Special
- Mitglied seit
- 17.08.2003
- Beiträge
- 5.193
- Renomée
- 142
- Standort
- Dresden - Germany
- Mein Laptop
- Dell Latitude XT2 (Samsung SSD 128GB-RBB)
- Prozessor
- Intel Q9550 2,83 @ 0,99 - 3,2
- Mainboard
- Asus P5Q-Deluxe
- Kühlung
- Coolermaster GeminII S
- Speicher
- 4 x 2GB DDR2 PC800 CL4 Corsair XMS2 DHX
- Grafikprozessor
- Asus GTX 960 Turbo 2G
- Display
- 30" Dell 3008WFP @2560x1600 & 22"LG @1650x1050
- SSD
- Crucial MX200 250 GB
- HDD
- 2x WD Velociraptor 300GB @ RAID 0 Intelcontroller
- Optisches Laufwerk
- Samsung DVD-RW/DL
- Soundkarte
- Creative X-Fi Titanium PCIe
- Gehäuse
- Zalman HD 160 Plus schwarz
- Netzteil
- BeQuiet 400W Pure Power L8
- Betriebssystem
- Win10 64Bit H + diverse in VMware
- Webbrowser
- FF
Hast Du überhaupt mal nen Blick in die Sundokumente geworfen, Die Fehleranalyse betrifft explizit auch die Metadaten ...
Ab lesen, dann klugscheissen!
Ab lesen, dann klugscheissen!
ghostadmin
Grand Admiral Special
https://blogs.oracle.com/bonwick/en_US/entry/raid_z
But far more important, going through the metadata means that ZFS can validate every block against its 256-bit checksum as it goes. Traditional RAID products can't do this; they simply XOR the data together blindly.
Which brings us to the coolest thing about RAID-Z: self-healing data. In addition to handling whole-disk failure, RAID-Z can also detect and correct silent data corruption. Whenever you read a RAID-Z block, ZFS compares it against its checksum. If the data disks didn't return the right answer, ZFS reads the parity and then does combinatorial reconstruction to figure out which disk returned bad data. It then repairs the damaged disk and returns good data to the application.
But far more important, going through the metadata means that ZFS can validate every block against its 256-bit checksum as it goes. Traditional RAID products can't do this; they simply XOR the data together blindly.
Which brings us to the coolest thing about RAID-Z: self-healing data. In addition to handling whole-disk failure, RAID-Z can also detect and correct silent data corruption. Whenever you read a RAID-Z block, ZFS compares it against its checksum. If the data disks didn't return the right answer, ZFS reads the parity and then does combinatorial reconstruction to figure out which disk returned bad data. It then repairs the damaged disk and returns good data to the application.
Meinst Du dieses Dokument? Wo steht da was über RAM Fehler, wenn es sich auf professtionelle Sun Storage der Serien 7310, 7320, 7410, 7420 und 7720 bezieht, die alle Xeon CPUs und reg. ECC RAM haben?
Bezeichnend für Leute die ECC bei ZFS für überflüssig halten ist eine selektive Wahrnehmung wie sie auch Jim Salter in dem Link aus Deinem letzten Post gezeigt hat, als er den aus Matthew Ahrens Beitrag zitierte:
Aber das muss jeder selbst wissen, mir ist es egal, es sind nicht meine Daten, mein Heimserver hat ECC RAM. Der einzige Vorteil von Nicht-ECC RAM ist der Preis, aber da auch weniger der des RAMs als der für die Plattform. Wobei da AMD im Vorteil ist, weil die ganzen AM3(+) CPUs und Chipsätze ECC RAM unterstützen und zumindest einige Boards von ASUS und Gigabyte. Bei Intel muss man dagegen auf ein teures Board mit Xeon Chipsatz und einen Celeron, Pentium, i3 oder Xeon ausweichen (oder einen der SoC die ECC unterstützen, aber das sind auch nicht die billigsten) und angeblich soll ECC RAM sogar beim AM1 mit dem Asus AM1M-A gehen.
Aber das muss eben jeder selbst entscheiden, darüber wird ja auch genug im Netz gestritten, hier geht es nicht um ZFS sollte das Thema damit hier durch sein, für mich ist es das jedenfalls.
--- Update ---
Bezeichnend für Leute die ECC bei ZFS für überflüssig halten ist eine selektive Wahrnehmung wie sie auch Jim Salter in dem Link aus Deinem letzten Post gezeigt hat, als er den aus Matthew Ahrens Beitrag zitierte:
. Dabei war seine Aussage aber:
Demnach ist man mit allen Filesystem gleich gefährdet, wobei der aber wegen der intensiveren RAM Nutzung von ZFS so nicht stimmt, denn je mehr RAM Daten belegen, umso wahrscheinlicher sind sie dann von RAM Fehler (egal ob soft- oder hard Errors) betroffen, aber der Vater wird sein Kind nicht schlechter als andere darstellen wollen. Dazu wurde dann auch sein klarer Hinweis das wer seine Daten liebt ECC RAM verwenden sollte, einfach von Jim Salter unter den Tisch fallen lassen, weil sie den Kontext gestört hätte.There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.
I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.
Aber das muss jeder selbst wissen, mir ist es egal, es sind nicht meine Daten, mein Heimserver hat ECC RAM. Der einzige Vorteil von Nicht-ECC RAM ist der Preis, aber da auch weniger der des RAMs als der für die Plattform. Wobei da AMD im Vorteil ist, weil die ganzen AM3(+) CPUs und Chipsätze ECC RAM unterstützen und zumindest einige Boards von ASUS und Gigabyte. Bei Intel muss man dagegen auf ein teures Board mit Xeon Chipsatz und einen Celeron, Pentium, i3 oder Xeon ausweichen (oder einen der SoC die ECC unterstützen, aber das sind auch nicht die billigsten) und angeblich soll ECC RAM sogar beim AM1 mit dem Asus AM1M-A gehen.
Aber das muss eben jeder selbst entscheiden, darüber wird ja auch genug im Netz gestritten, hier geht es nicht um ZFS sollte das Thema damit hier durch sein, für mich ist es das jedenfalls.
--- Update ---
Das bezieht sich auf die Nutzerdaten, nicht auf die Metadaten, die haben keine eigene 256bit ECC, wozu auch bei einem Filesystem welches für Server-HW geschrieben wurde, die die RAM Inhalte eben immer mit ECC RAM selbst vor Korruption schützt und welches sowieso schon viel RAM und CPU braucht.https://blogs.oracle.com/bonwick/en_US/entry/raid_z
But far more important, going through the metadata means that ZFS can validate every block against its 256-bit checksum as it goes. Traditional RAID products can't do this; they simply XOR the data together blindly.
Auch das ist alles auf die Nutzdaten bezogen, wären die Metadaten im RAM so gut geschützt, könnte es keine Fälle von zerstörten Pools gehen, aber die gibt es eben und RAM Fehler spielen da eben eine Rolle. Außerdem gibt es kein Recovery-Tool für die gecrashten Pools, das ist dann ein Totalverlust.Which brings us to the coolest thing about RAID-Z: self-healing data.
ghostadmin
Grand Admiral Special
Die Metadaten werden afaik erst dann verwendet wenn es auch notwendig ist d.h. wenn die Checksum eines Files nicht stimmt oder wenn eine Disk ausfällt.
Und ich habe schon gelesen das jemand den Pool recovern konnte mit korrupten Metadaten.
Regelmäßige Scrubs sollte man auch durchführen.
Und ich habe schon gelesen das jemand den Pool recovern konnte mit korrupten Metadaten.
Regelmäßige Scrubs sollte man auch durchführen.
yourgreatestfear
Grand Admiral Special
- Mitglied seit
- 17.08.2003
- Beiträge
- 5.193
- Renomée
- 142
- Standort
- Dresden - Germany
- Mein Laptop
- Dell Latitude XT2 (Samsung SSD 128GB-RBB)
- Prozessor
- Intel Q9550 2,83 @ 0,99 - 3,2
- Mainboard
- Asus P5Q-Deluxe
- Kühlung
- Coolermaster GeminII S
- Speicher
- 4 x 2GB DDR2 PC800 CL4 Corsair XMS2 DHX
- Grafikprozessor
- Asus GTX 960 Turbo 2G
- Display
- 30" Dell 3008WFP @2560x1600 & 22"LG @1650x1050
- SSD
- Crucial MX200 250 GB
- HDD
- 2x WD Velociraptor 300GB @ RAID 0 Intelcontroller
- Optisches Laufwerk
- Samsung DVD-RW/DL
- Soundkarte
- Creative X-Fi Titanium PCIe
- Gehäuse
- Zalman HD 160 Plus schwarz
- Netzteil
- BeQuiet 400W Pure Power L8
- Betriebssystem
- Win10 64Bit H + diverse in VMware
- Webbrowser
- FF
Schön gegoogelt nur leider nicht gelesen scheinbar. Die Quotes sind zum temporären WriteCache (die Debugflag ist für Scrubbing vorm Write, also zusätzliche Fehlercontrolle für den extrem flüchtigen Moment zwischen Queue und tatsächlichem Schreiben auf Platte), welcher in etwa wie bei jedem anderen transactional FS arbeitet. Daher hat ZFS hier die gleichen Risiken wie jedes andere FS, wenn man es ohne die Flag nutzt.
Der ARC hat mit dem WriteCache aber nix zu tun und ist eine Read-Extension dessen was auf der Disk passiert. Für den Inhalt arbeitet ZFS wohlverständlich und logischerweise mit den gleichen READ/WRITE-Algorithmen wie beim Direktzugriff auf Laufwerke, wobei aber ein Checksum- oder I/O-error zu einem Fallback aufs Laufwerk führt, statt zu einem Scrub. Die Dokumente, ordentlich studiert, zeigen Dir das für Daten wie auch Metadaten Fehler im ARC gleichartig zum Direktzugriff auf Laufwerken abgefangen werden und die Sicherungskette für die Datenintegrität weiterkickt in den Levels. Die einzige Sonderbehandlung für Metadaten im ARC besteht darin in welche Register er bei Fehlern weitermacht. Ein gekipptes Bit in den Metadaten würde unweigerlich zum Miss führen und den Zugriff auf L2ARC bzw. den Pool einleiten.
Es ist und bleibt nunmal so, das für die Datenintegrität der ARC keine zusätzliche Fehlerquelle ist, egal ob ECC oder nicht hier greift die ZFS-Fehlerkorrektur und Robustheit bzgl der Integrität. .. so bescheuert das Ding fehleranfälliger zu designen als den Direktzugriff auf Meta- und Blockdaten wäre kein Entwickler.
relevant wird ECC-RAM für den WriteCache des Transaktionssystems, und hier gibt es keine relevanten Besonderheiten im Vergleich zu anderen FS.
PS
Solange ihr in euren Argumenten Falschaussagen macht zu anderen FS/RAID-implementationen, ist es unumgänglich so ein leidseliges OffTopic zu betreiben. Wenn es euch nicht passt, dann lasst einfach derartiges Hörensagen und die Vermutungen bleiben. Man kann nicht alles wissen, gerade deswegen wäre ich vorsichtig mit dem weiterverbreiten irgendwelcher Weisheiten die man mal in einem Forum gelesen hat.
Der ARC hat mit dem WriteCache aber nix zu tun und ist eine Read-Extension dessen was auf der Disk passiert. Für den Inhalt arbeitet ZFS wohlverständlich und logischerweise mit den gleichen READ/WRITE-Algorithmen wie beim Direktzugriff auf Laufwerke, wobei aber ein Checksum- oder I/O-error zu einem Fallback aufs Laufwerk führt, statt zu einem Scrub. Die Dokumente, ordentlich studiert, zeigen Dir das für Daten wie auch Metadaten Fehler im ARC gleichartig zum Direktzugriff auf Laufwerken abgefangen werden und die Sicherungskette für die Datenintegrität weiterkickt in den Levels. Die einzige Sonderbehandlung für Metadaten im ARC besteht darin in welche Register er bei Fehlern weitermacht. Ein gekipptes Bit in den Metadaten würde unweigerlich zum Miss führen und den Zugriff auf L2ARC bzw. den Pool einleiten.
Es ist und bleibt nunmal so, das für die Datenintegrität der ARC keine zusätzliche Fehlerquelle ist, egal ob ECC oder nicht hier greift die ZFS-Fehlerkorrektur und Robustheit bzgl der Integrität. .. so bescheuert das Ding fehleranfälliger zu designen als den Direktzugriff auf Meta- und Blockdaten wäre kein Entwickler.
relevant wird ECC-RAM für den WriteCache des Transaktionssystems, und hier gibt es keine relevanten Besonderheiten im Vergleich zu anderen FS.
PS
hier geht es nicht um ZFS sollte das Thema damit hier durch sein, für mich ist es das jedenfalls.
Solange ihr in euren Argumenten Falschaussagen macht zu anderen FS/RAID-implementationen, ist es unumgänglich so ein leidseliges OffTopic zu betreiben. Wenn es euch nicht passt, dann lasst einfach derartiges Hörensagen und die Vermutungen bleiben. Man kann nicht alles wissen, gerade deswegen wäre ich vorsichtig mit dem weiterverbreiten irgendwelcher Weisheiten die man mal in einem Forum gelesen hat.
Zuletzt bearbeitet:
ghostadmin
Grand Admiral Special
definiere "ihr"
Ähnliche Themen
- Antworten
- 0
- Aufrufe
- 142K
- Antworten
- 0
- Aufrufe
- 234K