1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › ZFS ausprobiert: Ein Dateisystem…
  6. Thema

Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

Expertentalk zu DDR5-Arbeitsspeicher am 7.7.2020 Am 7. Juli 2020 von 15:30 bis 17:00 Uhr wird Hardware-Redakteur Marc Sauter eure Fragen zu DDR5 beantworten.
  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4

Neues Thema Ansicht wechseln


  1. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: HubertHans 12.10.17 - 22:24

    bccc1 schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > RAID Controller mit BBU braucht es spaetestens ab RAID 5.
    > Softwareloesungen
    > > sind da prinzipiell Murks. Einzig eine BBU sorgt dafuer, das die Stripes
    > > bei Stromausfall nicht geschaedigt werden. In Software ist das nciht
    > > machbar. Auch die angeblichen Wunderdateissysteme wie ZFS oder BTRFS
    > > koennen das nicht gewaehrleisten, auch wenn hier immer wieder vorgebetet
    > > wird, das bei Stromausfall nix passieren kann. Physik existiert da dann
    > > fuer diese Leute einfach nicht mehr. Oder sie steigen da einfach nicht
    > > durch...
    >
    > Was verstehst du unter "Stripes nicht geschädigt werden"? Falls es darum
    > geht, ein inkonsistenten Dateisystemzustand zu vermeiden, dann kann ZFS
    > genau das doch.

    Ein RAID 5/ 6 arbeitet mit Stripes. Weißt du, wie hier ein Schreibvorgang bewaeltigt wird? Ist ein Stripe defekt, kann es bei einem Rebuild zum Gau fuehren. Und zu einem richtig unschoenen Datenverlust. Also im Extremfall ist das RAID verloren, wenn keine BBU existiert. RAID 1 und RAID 0 dagegen sind hier nicht so anfaellig. Bei RAID 0 ists voellig egal, bei RAID 1 muss nur synchronisiert werden.

    Bei der Wiederherstellung der Integritaet kann es dann bei RAID 0 oder 1 zu Datenverlust kommen, die Dateissystemstruktur und die des RAID ist dabei jedoch nicht gefaehrdet. Bei RAID 0 reicht Checkdisk. (Solange man ein Dateissystem nutzt welches wie NTFS zwei MFTs oder Vergleichbares mit sich traegt) Bei RAID 5 oder RAID 6 dagegen ist mit Pech ein Stripe unwiderruflich beschaedigt. Dafuer muessen am Besten Monatlich, auch mit BBUs, komplette "Verify/ Fix"-Vorgaenge ausgefuehrt werden, um die Datenstruktur sicher zu halten. Taucht so ein Fehler erst bei einem Rebuild auf, bist du der Firmware des Controllers ausgeliefert. Backup ist dann hoffentlich in der NAehe.

    Bei einem Dateissystem muessen die Daten und eben auch die Verlinkung existieren. Bei NFS oder BRTFS liegen zu viele Daten im fluechtigen Schreibcache. Das Risiko eines Datenverlustes bei Stromausfall oder Absturz liegt hier ungleich hoeher. Waehrend ein RAID-Controller mit BBU beim Neustart einfach seinen Cache leert oder der Cache sogar zu einem neuen Controller uebertragen werden kann, sind bei einem Software-RAID oder solchen Dateissystemen, die wie ein SW-RAID agieren die Daten dann einfach weg. Und es kann sich dabei um mehrere Megabytes bis Gigabytes handeln. Selbst wenn diese an sich schon geschrieben wurden. Denn den Abschluss des Schreibvorgangs waehre sich ein Controller mit BBU bewusst. Das OS jedoch, tja... Desqwegen verlagert man den Schreibcache lieber auf den Controller.

    > Es werden ja keine Daten überschrieben, so dass nach dem Crash ZFS erkennt,
    > das die halb beschriebenen Blöcke genau das sind und somit verworfen
    > werden. Das System ist in einem konsistenten Zustand, nur die letzten
    > Datenänderungen sind verloren.

    Eben. Mit einem RAID Controller mit BBU laesst sich dieser Datenverlust noch weiter minimieren. Die Wahrscheinlichkeit eines Datenverlustes reduziert sich dann, wenn der Controlelr und Laufwerke einwandfrei arbeiten, auf Faelle, wo Programme die Daten erfassen und der Stromausfall/ Absturz auftreten oder eben das Schciken der Daten an den Controller nciht vollstaendig verlaufen ist. Die Konsitenz des RAID bleibt jedoch garantiert erhalten, auch wenn Datenverlust entsteht. Das ist das Tolle daran. ZFS oder BRTFS haben keine Moeglichkeit, das sicherzustellen. Du erwaehnst hier nur den optimalen Fall. Was ist, wenn nur das letzte Byte des Schreibvorgangs nicht abgeschlossen wurde?

    >
    > Falls es dir um den Verlust der Daten geht, die gerade geschrieben wurden,
    > dann hast du natürlich recht. Wenn die zu schreibenden Daten so wichtig
    > sind, dass das nicht verkraftbar ist, sollte der Client halt synchron
    > schreiben. Dann wird das nicht gecached sondern direkt auf HDD geschrieben

    Kein Cache? Das ist lahm. Cache gibts nicht ohne Grund. Write Back ist eine extrem wichtige Angelegenheit. Und auch mit Abschalten des Cache loest du das von mir genannte Problem nciht. Du reduzierst nur das Zeitfenster fuer genannte Schaeden.

    > und nach fertigstellung gibts ein Feedback an den Client. Wenn dann das
    > System crashed, hat der Client zumindest keine Fehlerhafte Annahme über den
    > Zustand auf dem System und kann uU warten bis das System wieder online ist
    > und dann den Schreibvorgang wiederholen.

    Mit Batteriepuffer kannst du aber sicherstellen, das die Daten, die im Puffer lagen, noch geschrieben werden koennen. Vielleicht sogar mit dem genannten Feedback ueber den Abschluss des Vorgangs. Das ist der Unterschied.

    > Davon abgesehen, wenn zwei USVs via redundanter Netzteile an dem Server
    > angeschlossen sind, wird eine BBU äußerst selten benötigt werden.

    USVs haben mit BBUs nichts gemein. BBUs schuetzen auch bei Abstuerzen des Systems vor Beschaedigung des RAIDs. Oder beim Reset/ Ausschalten. (Versehentlich oder Absichtlich) Die USV ist ein zusaetzliches Instrument. Einen Zusammenhang zwischen diesen beiden Dingen gibt es jedoch nicht. Das ist eine Fehleinschaetzung, die viele machen.

    >
    > Oder übersehe ich da was? Ich bin bei weitem kein ZFS Experte.

    Ich bin auch kein ZFS-Experte. Aber Physik laesst sich nicht außer Kraft setzen. Wir benutzen z.B. deswegen mehrere redundante Server, RAID 5 (Da mehrere Server, nicht nur zwei existieren, waere RAID 6 eine Verschwendung) als Grundlage und arbeiten dann mit entsprechenden Dateissystemen, die den Job je nach OS am Besten gewaehrleisten.

    Softwarebasierende Speichertechniken werden gerne im privaten Umfeld genutzt (Hier oft eher aus Unwissen, speziell wenn dann zu RAID5 oder 6 gegriffen wird), weil sie nichts kosten. RAID 1 oder RAID 0 in Software sind schnelle, guenstige und robuste Loesungen. Speziell RAID 0 ist unanfaellig gegenueber Systemabstuerzen usw. (Auch wenn hier keinerlei Schutz vor Ausfall besteht)

    Dann kehrt sich das Verhaeltniss der Preis Leistung bei sehr großen Serverfarmen wieder in eine positive Richtung, im Gegensatz zu kleinen und mittelgroßen Firmen. Der betrieb von Servern mit einfachen Platten und Software-RAIDs/ ZFS &Co wird dann wieder billiger. Man plant die Ausfallwahrscheinlichkeit mit ein und spart sich teuere Controller.

  2. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: HubertHans 12.10.17 - 22:25

    pumok schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    >
    > > Softwareloesungen taugen als solche nicht fuer einen stabilen Betrieb.
    > > Softwareloesungen sind Spielkram.
    >
    > Ich verstehe, Du magst Software RAID nicht. Das ist Ok und geht mich auch
    > nichts an.

    Ich nutze Software-RAID. Aber nur RAID 0 oder RAID 1. ARAID 5/ RAID 6 mit Parity ist prinzipell als Softwareloesung unbrauchbar,

    > Aber deswegen solche Unwahrheiten zu erzählen, finde ich persönlich
    > schwach.

    Dann stelle es doch richtig. Beweise mir, das RAID 5 oder RAID 6 als Softwareloesung einen sicheren Betrieb gewaehrleistet. Und blamiere dich.

  3. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: YarYar 13.10.17 - 08:04

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Dann stelle es doch richtig. Beweise mir, das RAID 5 oder RAID 6 als
    > Softwareloesung einen sicheren Betrieb gewaehrleistet. Und blamiere dich.

    Die typische Argumentation von Esoterikern und Ufo Forschern: "Was sie auf dem Foto sehen ist ein UFO. Sie glauben mir nicht? Dann beweisen sie mir doch das es kein UFO ist."

    Umkehrt der Beweislast.

  4. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: pumok 13.10.17 - 09:23

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Ich nutze Software-RAID. Aber nur RAID 0 oder RAID 1. ARAID 5/ RAID 6 mit
    > Parity ist prinzipell als Softwareloesung unbrauchbar,
    >
    > Dann stelle es doch richtig. Beweise mir, das RAID 5 oder RAID 6 als
    > Softwareloesung einen sicheren Betrieb gewaehrleistet. Und blamiere dich.

    Falsch, Du behauptest hier aus dem Nichts etwas, das Du nicht begründen kannst. Es ist also an Dir etwas zu beweisen.
    Nur so als Hinweis: ZFS und ähnliche FS werden nicht von Privatpersonen oder Kleinunternehmen entwickelt, sondern von echten Grössen der Branche. Denkst Du im Ernst, die würden soviele Ressourcen für diese Entwicklung einsetzen, wenn alles nur Müll wäre?

    Ich brauche mich nicht zu blamieren, das hast Du schon für mich erledigt :-)

  5. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: HubertHans 13.10.17 - 10:09

    YarYar schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Dann stelle es doch richtig. Beweise mir, das RAID 5 oder RAID 6 als
    > > Softwareloesung einen sicheren Betrieb gewaehrleistet. Und blamiere
    > dich.
    >
    > Die typische Argumentation von Esoterikern und Ufo Forschern: "Was sie auf
    > dem Foto sehen ist ein UFO. Sie glauben mir nicht? Dann beweisen sie mir
    > doch das es kein UFO ist."
    >
    > Umkehrt der Beweislast.

    Esoterik? Du wuerdest meine Aussage verstehen, wenn du verstehst, wie RAID 5 und RAID 6 arbeiten. Aber dafuer fehlt dir das notwendige Hirnschmalz. Und wieso Umkehrung der Beweislast? Das ist Basiswissen. Niemand der das Konzept verstanden hat wird ein RAID5 oder RAID 6 auf Softwarebasis verwenden, der eine hohe Verfuegbarkeit benoetigt. Oder bzw: Ist sich bei Verwendung von RAID 5/ RAID 6 der durch diese Funktion auftretenden Probleme bewusst. Und die Hersteller von RAID Controllern haben nicht umsonst BBUs fuer deren Controller im Paket. Aber quatsch du nur.



    1 mal bearbeitet, zuletzt am 13.10.17 10:14 durch HubertHans.

  6. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: HubertHans 13.10.17 - 10:13

    pumok schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich nutze Software-RAID. Aber nur RAID 0 oder RAID 1. ARAID 5/ RAID 6
    > mit
    > > Parity ist prinzipell als Softwareloesung unbrauchbar,
    > >
    > > Dann stelle es doch richtig. Beweise mir, das RAID 5 oder RAID 6 als
    > > Softwareloesung einen sicheren Betrieb gewaehrleistet. Und blamiere
    > dich.
    >
    > Falsch, Du behauptest hier aus dem Nichts etwas, das Du nicht begründen
    > kannst. Es ist also an Dir etwas zu beweisen.

    Auch fuer dich. Das ist Basiswissen. Das du das Basiswissen nicht beherrscht und keine Ahnung hast ist dein Problem. Es ist nicht meine Aufgabe, dir das Grundverstaendniss fuer die Arbeitsweise und die dadurch entstehenden Schwaechen des Systems auskunft zu geben, wenn diese allgemein bekannt sind.

    > Nur so als Hinweis: ZFS und ähnliche FS werden nicht von Privatpersonen
    > oder Kleinunternehmen entwickelt, sondern von echten Grössen der Branche.
    > Denkst Du im Ernst, die würden soviele Ressourcen für diese Entwicklung
    > einsetzen, wenn alles nur Müll wäre?

    Ich habe nie behauptet, das das Muell waere. Nur reden Leute dummes Zeug und Glauben, das sich Physik mit solchen Wunderdateissystemen außer Kraft setzen laesst.

    Deswegen habe ich bereits mehrere Herangehensweisen genannt, um auftretende Probleme zu minimieren.

    >
    > Ich brauche mich nicht zu blamieren, das hast Du schon für mich erledigt
    > :-)

    Ja. Dunning Krueger Effekt ist hier sehr weit verbreitet, das weiß ich schon laenger. Wenn ihr nicht einmal das Grundwissen dabei habt, wofuer seit ihr hier?



    1 mal bearbeitet, zuletzt am 13.10.17 10:15 durch HubertHans.

  7. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: pumok 13.10.17 - 10:37

    Du bist ja ein lustiger :-)

    Vielleicht solltest Du den "Experten" von Sun/Oracle mal erklären, dass sie keine Ahnung haben und zu Dir in die Schulung müssen, bevor sie wieder ein neuens FS entwickeln, welches Spielkram ist und niemals stabil funktionieren kann.

    In einem Punkt gebe ich Dir jedoch recht, das ist Basiswissen. Jemand der die Basis verstanden hat, der kann allerdings technisch Argumentieren anstatt nur unter der Gürtellinie Sprüche zu klopfen.



    1 mal bearbeitet, zuletzt am 13.10.17 10:44 durch pumok.

  8. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: bccc1 13.10.17 - 11:30

    Deine Ausführen zu BBUs klingen soweit ja alle richtig aber ich habe das Gefühl du hast von ZFS zu wenig Ahnung um so vehement darauf zu bestehen, dass die Gesetze der Physik das unzuverlässig machen. Zugegeben, mit meinem Halbwissen bin ich auch nicht in der besten Position das zu behaupten ;)
    Da ZFS auch bei einer Änderung erst die neuen Daten in andere, leere Sektoren schreibt und dann vermerkt, dass diese neuen Daten geschrieben wurden und die alten sektoren nun als leer gelten, kann das System durch ein plötzlichen Abbruch nicht kaputt gehen. Wenn nicht zu ende geschrieben wurde, fehlt der Eintrag das diese Daten nun gültig sind. Wenn zu Ende geschrieben wurde, aber im letzten Moment beim Schreiben des Eintrags das System abschmiert, müsste ZFS die Eintragung als fehlerhaft erkennen und verwerfen. Der einzige mir bekannte Weg ein ZFS Dateisystem zum Datenverlust zu bringen, ist entweder RAM ohne ECC und seeeeeeeeehr viel Pech oder der Ausfall von zuvielen Datenträgern. Oder natürlich Anwenderfehler vom Admin.

    Auf YouTube hab ich mal ein Video gesehen wo die sich bemüht haben Datenverlust unter ZFS herbeizuführen. Die haben während Daten geschrieben wurden den Strom getrennt, RAM entfernt und dem RAM Stromstöße verpasst. Jedes mal waren zwar die Daten weg die noch nicht geschrieben werden konnten, aber es gab keine Schäden an anderen Dateien oder dem Dateisystem selbst. Am Ende haben sie mit den Stromstößen das Mainboard gegrillt. In einem neuen PC konnten die dabei unbeschädigten HDDs dann weitergenutzt werden, ebenfalls kein Schaden am Dateisystem.


    Was ich sagen will: Ja, mit ZFS kannst du die noch nicht geschrieben Daten verlieren und da kann eine BBU besser sein. Das gilt aber nur für asynchrones Schreiben. Davon abgesehen ist ZFS aber robuster als jedes Hardware RAID das ich kenne.

    Wenn der Schreibvorgang synchron läuft, kann es nicht vorkommen, dass ZFS die Daten nicht schreibt, der Client aber glaubt, das geschrieben wurde.
    Damit das nicht zu lahm wird, gibt es das ZFS Intent Log (ZIL), das kann z.B. eine einfache SATA SSD, ein RAID10 aus NVMe SSDs oder battery-backed RAM sein. Alle synchronen Schreiboperationen werden hier hingeschrieben, dann wird dem Client zurückgemeldet dass das write erfolgreich war. ZFS schreibt den Kram aus dem ZIL dann später auf den eigentlichen Storage Pool.

    Ich will damit nicht sagen ZFS sei der Messias. Natürlich gibt es Fälle, wo ein Hardware RAID Controller die bessere Wahl ist. Ich wollte die Aussage "Softwareloesungen taugen als solche nicht fuer einen stabilen Betrieb. Softwareloesungen sind Spielkram." berichtigen.



    1 mal bearbeitet, zuletzt am 13.10.17 11:46 durch bccc1.

  9. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: HubertHans 13.10.17 - 12:23

    pumok schrieb:
    --------------------------------------------------------------------------------
    > Du bist ja ein lustiger :-)
    >
    > Vielleicht solltest Du den "Experten" von Sun/Oracle mal erklären, dass sie
    > keine Ahnung haben und zu Dir in die Schulung müssen, bevor sie wieder ein
    > neuens FS entwickeln, welches Spielkram ist und niemals stabil
    > funktionieren kann.

    Ich habe auch geschrieben, wie man dagegen arbeitet. Und BBUs sind nur eine Moeglichkeit. Ab einer gewissen Groeße hat man eben so viele Mirrors, das eine BBU nicht unbedingt mehr bringt im Verhaeltniss.

    >
    > In einem Punkt gebe ich Dir jedoch recht, das ist Basiswissen. Jemand der
    > die Basis verstanden hat, der kann allerdings technisch Argumentieren
    > anstatt nur unter der Gürtellinie Sprüche zu klopfen.

    Ich habe die Probleme beschrieben. Du hast sie nicht verstanden. Weil dir das Basiswissen fehlt. Oder eben die Intelligenz.



    1 mal bearbeitet, zuletzt am 13.10.17 12:32 durch HubertHans.

  10. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: HubertHans 13.10.17 - 12:31

    bccc1 schrieb:
    --------------------------------------------------------------------------------
    > Deine Ausführen zu BBUs klingen soweit ja alle richtig aber ich habe das
    > Gefühl du hast von ZFS zu wenig Ahnung um so vehement darauf zu bestehen,
    > dass die Gesetze der Physik das unzuverlässig machen. Zugegeben, mit meinem
    > Halbwissen bin ich auch nicht in der besten Position das zu behaupten ;)
    > Da ZFS auch bei einer Änderung erst die neuen Daten in andere, leere
    > Sektoren schreibt und dann vermerkt, dass diese neuen Daten geschrieben
    > wurden und die alten sektoren nun als leer gelten, kann das System durch
    > ein plötzlichen Abbruch nicht kaputt gehen. Wenn nicht zu ende geschrieben
    > wurde, fehlt der Eintrag das diese Daten nun gültig sind. Wenn zu Ende
    > geschrieben wurde, aber im letzten Moment beim Schreiben des Eintrags das
    > System abschmiert, müsste ZFS die Eintragung als fehlerhaft erkennen und
    > verwerfen. Der einzige mir bekannte Weg ein ZFS Dateisystem zum
    > Datenverlust zu bringen, ist entweder RAM ohne ECC und seeeeeeeeehr viel
    > Pech oder der Ausfall von zuvielen Datenträgern. Oder natürlich
    > Anwenderfehler vom Admin.

    Aber du beschreibst doch schon ein Problem,welches sich mit einem RAID Controller mit BBU decken laesst. Statt sich darauf zu verlassen, das das Dateissystem erkennt, das da was fehlt (Was bei Unvollkommenden Daten eben nciht unbedingt zur Erkennung eines Fehlers sondern auch zu Fehlverhalten fuehren kann) deckt man dies eben mit weiteren Maßnahmen ab. Welche ich genannt habe. Preis/ Leistung ist entscheidend.

    >
    > Auf YouTube hab ich mal ein Video gesehen wo die sich bemüht haben
    > Datenverlust unter ZFS herbeizuführen. Die haben während Daten geschrieben
    > wurden den Strom getrennt, RAM entfernt und dem RAM Stromstöße verpasst.
    > Jedes mal waren zwar die Daten weg die noch nicht geschrieben werden
    > konnten, aber es gab keine Schäden an anderen Dateien oder dem Dateisystem
    > selbst. Am Ende haben sie mit den Stromstößen das Mainboard gegrillt. In
    > einem neuen PC konnten die dabei unbeschädigten HDDs dann weitergenutzt
    > werden, ebenfalls kein Schaden am Dateisystem.

    Ja. Aber das ist doch nichts besonderes. Selbst NTFS hat diese Moeglichkeiten. Schaeden am Dateissystem gibt es trotzdem. Die dann durch die Selbstheilungsfaehigkeit des Dateissystems oder eben Reparaturmaßnahmen behoben werden.

    >
    >
    > Was ich sagen will: Ja, mit ZFS kannst du die noch nicht geschrieben Daten
    > verlieren und da kann eine BBU besser sein. Das gilt aber nur für
    > asynchrones Schreiben. Davon abgesehen ist ZFS aber robuster als jedes
    > Hardware RAID das ich kenne.

    Das kann man bejahen. Fuer Hardware-RAIDs sind zusaetzliche Komponenten und Herangehensweisen noetig. ZFS als Beispiel bleibt bei einem Minimum. Mit einem RAID laesst sich jedoch, wenn man die Investition leistet und sie sich lohnt, ZFS an sich noch stabiler aufstellen mit weniger Risiko eines Datenverlust von schwebenden Daten.

    >
    > Wenn der Schreibvorgang synchron läuft, kann es nicht vorkommen, dass ZFS
    > die Daten nicht schreibt, der Client aber glaubt, das geschrieben wurde.
    > Damit das nicht zu lahm wird, gibt es das ZFS Intent Log (ZIL), das kann
    > z.B. eine einfache SATA SSD, ein RAID10 aus NVMe SSDs oder battery-backed
    > RAM sein. Alle synchronen Schreiboperationen werden hier hingeschrieben,
    > dann wird dem Client zurückgemeldet dass das write erfolgreich war. ZFS
    > schreibt den Kram aus dem ZIL dann später auf den eigentlichen Storage
    > Pool.

    Jupp. Das waere ebenfalls eine entsprechende Maßnahme. Batteriegepufferter RAM ist an sich schon ein alter Hut. Hatte mal ein 286er Notebook, welches ebenfalls gepufferten RAM hatte.. Ideal. Nur bei einem Absturz schuetzte es nicht, falls Schreibvorgaenge nicht abgeschlossen wurden.

    >
    > Ich will damit nicht sagen ZFS sei der Messias. Natürlich gibt es Fälle, wo
    > ein Hardware RAID Controller die bessere Wahl ist. Ich wollte die Aussage
    > "Softwareloesungen taugen als solche nicht fuer einen stabilen Betrieb.
    > Softwareloesungen sind Spielkram." berichtigen.

    RAID 5 und RAID 6 taugen nicht als Softwareloesung im kleinen und mittleren Bereich. Da man sich damit eine erhoehte Ausfallwahrscheinlichkeit schafft. Und, wenn man diese minimiert, Performanz verliert. Bei RAID 5 oder RAID 6 (Oder aehnlichen Typen) muss man es richtig machen. Oder man kann es gleich lassen.

  11. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: pumok 13.10.17 - 12:51

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Das kann man bejahen. Fuer Hardware-RAIDs sind zusaetzliche Komponenten und
    > Herangehensweisen noetig. ZFS als Beispiel bleibt bei einem Minimum. Mit
    > einem RAID laesst sich jedoch, wenn man die Investition leistet und sie
    > sich lohnt, ZFS an sich noch stabiler aufstellen mit weniger Risiko eines
    > Datenverlust von schwebenden Daten.

    Da kannst Du noch lange auf der angeblichen Dummheit Deiner Kontrahenten rumreiten. Mit dieser Aussage hast Du definitiv bewiesen, dass Du null Ahnung von ZFS hast.
    RAID Controller mit ZFS ist ein Schwerverbrechen und macht absolut keinen Sinn.

    Ich bin raus, das getrolle brauche ich nicht.
    Trotzdem ein schönes Weekend Euch allen :-)

  12. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: HubertHans 13.10.17 - 13:00

    pumok schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das kann man bejahen. Fuer Hardware-RAIDs sind zusaetzliche Komponenten
    > und
    > > Herangehensweisen noetig. ZFS als Beispiel bleibt bei einem Minimum. Mit
    > > einem RAID laesst sich jedoch, wenn man die Investition leistet und sie
    > > sich lohnt, ZFS an sich noch stabiler aufstellen mit weniger Risiko
    > eines
    > > Datenverlust von schwebenden Daten.
    >
    > Da kannst Du noch lange auf der angeblichen Dummheit Deiner Kontrahenten
    > rumreiten. Mit dieser Aussage hast Du definitiv bewiesen, dass Du null
    > Ahnung von ZFS hast.
    > RAID Controller mit ZFS ist ein Schwerverbrechen und macht absolut keinen
    > Sinn.
    >
    > Ich bin raus, das getrolle brauche ich nicht.
    > Trotzdem ein schönes Weekend Euch allen :-)

    Dann begruende das doch einmal mit Fakten...

    Du hast keine Ahnung wovon du redest und was im Hintergrund ablaeuft. Und du wirfst mir Inkompetenz vor. Du erliegst dem Dunning Krueger Effekt. Um meine Aussage zu verstehen wuerde schon der Blick in die Wikipedia helfen, wenn du denn in der Lage waerst, die Hintergruende zu erfassen.

    Apropo: Nur weil man auf ein Feature von ZFS verzichtet und das auf eine Ebene tiefer ansetzt, wird der Einsatz von ZFS nicht automatisch nutzlos. Man kann sogar mehrere logische Laufwerke zusammen schließen. Was sehr effizient sein kann. Oder man kann es lassen.



    2 mal bearbeitet, zuletzt am 13.10.17 13:11 durch HubertHans.

  13. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: Jürgen Troll 13.10.17 - 13:17

    Oder man unterlässt es erstmal, seinen Gegenüber mit jedem Beitrag als unfähig hinzustellen oder mangelnde Intelligenz vorzuwerfen. Das bewirkt nämlich eher das Gegenteil.

  14. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: YarYar 13.10.17 - 13:18

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Du erliegst dem Dunning Krueger Effekt.

    "Dunning und Kruger hatten in vorausgegangenen Studien bemerkt, dass Unwissenheit oft zu mehr Selbstvertrauen führt als Wissen. "

    Traumhaft. You made my day! :-) :-)

    In diesem Zusamenhang empfehle ich dir auch folgenden Artikel: https://de.wikipedia.org/wiki/Selbsterkenntnis

    :-) :-) :-)

  15. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: YarYar 13.10.17 - 13:28

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Apropo: Nur weil man auf ein Feature von ZFS verzichtet und das auf eine
    > Ebene tiefer ansetzt, wird der Einsatz von ZFS nicht automatisch nutzlos.
    > Man kann sogar mehrere logische Laufwerke zusammen schließen. Was sehr
    > effizient sein kann. Oder man kann es lassen.

    Das Thema ZFS und RAID Controller ist schon an vielen Stellen diskutiert worden. Offensichtlich hast du aber nichts davon gelesen. Ich empfehle es dir mal zu google'n.

    Zusammengefasst geben die Experten folgenden Rat: Hat der RAID Controller eine BBU dann solle man die Disks einzeln durchreichen (JBOD) und ZFS damit einen pool aufbauen lassen. So kann man noch von der BBU profitieren.

    Man sollte nicht mit dem Controller das RAID aufsetzen und dann ZFS darüber installieren, denn dann beschneidet man ZFS in seinen Fähigkeiten.

    Ich bin jetzt aber auch im Wochenende. Und Tschuess.

  16. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: HubertHans 13.10.17 - 13:36

    Jürgen Troll schrieb:
    --------------------------------------------------------------------------------
    > Oder man unterlässt es erstmal, seinen Gegenüber mit jedem Beitrag als
    > unfähig hinzustellen oder mangelnde Intelligenz vorzuwerfen. Das bewirkt
    > nämlich eher das Gegenteil.

    Was und wie soll man denn sonst sagen?

  17. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: HubertHans 13.10.17 - 13:37

    YarYar schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Du erliegst dem Dunning Krueger Effekt.
    >
    > "Dunning und Kruger hatten in vorausgegangenen Studien bemerkt, dass
    > Unwissenheit oft zu mehr Selbstvertrauen führt als Wissen. "
    >
    > Traumhaft. You made my day! :-) :-)
    >
    > In diesem Zusamenhang empfehle ich dir auch folgenden Artikel:
    > de.wikipedia.org
    >
    > :-) :-) :-)

    Hahaha. Dummerweise hab ich mit dem Thema schon sehr lange was am Hut und musste mich mit der Materie auseinandersetzen.

  18. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: HubertHans 13.10.17 - 13:44

    YarYar schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Apropo: Nur weil man auf ein Feature von ZFS verzichtet und das auf eine
    > > Ebene tiefer ansetzt, wird der Einsatz von ZFS nicht automatisch
    > nutzlos.
    > > Man kann sogar mehrere logische Laufwerke zusammen schließen. Was sehr
    > > effizient sein kann. Oder man kann es lassen.
    >
    > Das Thema ZFS und RAID Controller ist schon an vielen Stellen diskutiert
    > worden. Offensichtlich hast du aber nichts davon gelesen. Ich empfehle es
    > dir mal zu google'n.
    >
    > Zusammengefasst geben die Experten folgenden Rat: Hat der RAID Controller
    > eine BBU dann solle man die Disks einzeln durchreichen (JBOD) und ZFS damit
    > einen pool aufbauen lassen. So kann man noch von der BBU profitieren.

    Auch eine Moeglichkeit. Hilft jedoch weniger bei einem Hardwaredefekt. Bei einem bestehendem RAID waere das im Fehlerfall fuer das ZFS transparent. Bei einzelnen Platten muss ZFS als Fehlerkorrektur herhalten. Ich wuerde mich da, je nach Anforderung, eher auf den Controller verlassen. Mit den Selbstheilungsmoeglichkeiten von ZFS oben drauf. Das ZFS oder andere Dateissysteme Moeglichkeiten zum Erhalt der Datenstruktur ueber mehere Datentraeger besitzen bedeutet nicht auch automatisch, das es die optimale Moeglichkeit darstellt.

    Edit: und einen Vorteil hat man eben bei RAID 5/ RAID 6 und entsprechenden Controller obendrauf: Die regelmaeßige Pruefung auf die Fehlerfreiheit der vorhandenen Datenstruktur des RAID. Festplatten und SSDs haben eine gewissen Wahrscheinlichkeit, dass unkorrigierbare Schreib/ Lesefehler auftreten. Auch das koennte so transparent fuer ZFS im Hintergund erfolgen. Nicht das ZFS im Fehlerfall einfach nur erkennt, dass ein Fehler beim Auslesen auftrat.

    >
    > Man sollte nicht mit dem Controller das RAID aufsetzen und dann ZFS
    > darüber installieren, denn dann beschneidet man ZFS in seinen Fähigkeiten.

    Was keine Relevanz hat. (Was sich auf das Beschneiden von Features bezieht) Die Frage ist, was in welchem Moment an Anforderungen besteht. Wer so denkt hat schon verloren.

    >
    >
    > Ich bin jetzt aber auch im Wochenende. Und Tschuess.

    Ebenfalls. Ich muss weg. Habe alles gesagt. Betreffende Person kann sich ja noch gerne darin waelzen, keine Ahnung zu haben. Vielleicht geht auch dieser Person irgendwann ein Licht auf.



    2 mal bearbeitet, zuletzt am 13.10.17 13:50 durch HubertHans.

  19. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: Stormking 13.10.17 - 16:34

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > ZFS
    > oder BRTFS haben keine Moeglichkeit, das sicherzustellen.

    Doch, genau dafür ist das ZFS Intent Log (ZIL) da. Und wenn man das auf eine schnelle SSD legt, dann funktioniert es letztlich genau wie einer dieser neueren RAID-Controller, die statt einer BBU eine kleine SSD verbaut haben.

  20. Re: Auf NAS/Backup-Systemen wird ZFS aber schnell anstrengend

    Autor: GAK 14.10.17 - 17:50

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Habe alles gesagt.
    Und unglaublich viele sachliche Fehler, in sehr unsachlicher Form, verbreitet.

    Es macht keinen Sinn ZFS mit einem Hardware-RAID zu backen, damit wirfst Du nur sinnlos Resourcen und Möglichkeiten zur Fehlerbehebung weg, da ZFS dann nicht mehr die einzelnen Platten sieht und die dortigen Platten mit den vorhandenen Prüfsummen vergleichen und ggf. einen Fehler auf einer einzelnen beheben kann - sondern nur noch den Müll den der Controller ggf. liefert sieht und nur noch 'Daten kaputt' sagen kann.

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. AKKA, Ingolstadt
  2. Diehl Metering GmbH, Ansbach/Nürnberg, Bazanowice (Polen)
  3. CodeCamp:N GmbH, Nürnberg
  4. ERGO Group AG, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-47%) 21,00€
  2. (-87%) 2,50€
  3. (u. a. Warhammer 40,00€0: Gladius - Relics of War für 23,79€, Aggressors: Ancient Rome für 17...


Haben wir etwas übersehen?

E-Mail an news@golem.de