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

  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: ArcherV 11.10.17 - 16:50

    Mixermachine schrieb:
    --------------------------------------------------------------------------------
    > Soweit ich es verstanden habe, scannt ein neuer Controller gleich nach
    > Platten und kann ein altes Raid 5 wieder einhängen.
    > Der Controller muss natürlich vom gleichen Typ sein.

    Ja und genau das ist ja der Knackpunkt!
    Wenn du einen gebrauchten gekauft hast, musst du dir erstmal einen neuen und baugleichen Controller besorgen (oder gleich zwei gebrauchte kaufen und hoffen, dass der andere überlebt).

    Den hick hack möchte ich mir im privaten Umfeld einfach nicht antun.

    Außerdem haben die Windows Storage Pools auch noch nette Features wie z.B. Datendeduplizierung*.

    * nur auf Windows Server / Storage Server, die Storage Pools selbst sind hingegen auch im Windows ab Version 8 enthalten

    > und zusätzlich
    > noch schwerer Abzusichern.

    Also das kann ich nicht so stehen lassen! Windows ist nicht per se unsicherer als dein Debian oder Ubuntu.
    Viel mehr hängt es doch vom persönlichen Know How ab. Arbeitsbedingt habe ich sehr viel Erfahrung mit Windows, mir fällt es also recht einfach ein Windows abzuhärten. Ein Debian Server hingegen? Da müsste ich mich erstmal einlesen und würde bestimmt die ein oder andere Sachen übersehen. In meinem Falle wäre der Debian Server also unsicherer.

    Meine Webseiten laufen bis jetzt z.B. auch alle ohne Probleme auf einem Windows Server ;).
    Und ohne GUI geht ja auch, das ist also kein Argument.

    > So läuft jetzt eine Debian VM, die für alle anderen VMs auf dem Esxi und im
    > Netzwerk verschlüsselten Speicher bereitstellt.
    > Da läuft sonst nichts anderes mehr.

    So ein ESXI ist ja schon eine schöne Spielerei, hatte ich mir des Spaßeshalber auch mal aufgesetzt, die Single Lizenz ist ja kostenlos. Bin dann aber doch HyperV genommen, ist für meine Zwecke deutlich sinnvoller und auch komfortabler :)



    1 mal bearbeitet, zuletzt am 11.10.17 16:52 durch ArcherV.

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

    Autor: YarYar 11.10.17 - 16:51

    Floyddotnet schrieb:
    --------------------------------------------------------------------------------
    > Falsch. In btrfs kann ich beliebg große platten einem pool dazufügen.
    >
    > Einfach mit:
    > btrfs device add /neuesDevice /mnt
    >
    > Je nach RAID-Level und füllstand kann ein balance-lauf noch notwendig sein
    > um die datein neu zu verteilen:
    >
    > btrfs balance start /mnt

    Ja natürlich. Das geht auch mit mdadm. Aber du kannst von der größeren Platte nur den Teil nutzen der mit den kleineren Platten überlappt. Der Rest ist verschwendet. Insofern macht es keinen Sinn eine 2 TB in ein 10x 1TB RAID zu hängen.

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

    Autor: KarlaHungus 11.10.17 - 16:57

    ChriDDel schrieb:
    --------------------------------------------------------------------------------
    > Mein Microserver 40L schafft mehr als 90MB/s im 1GB/s Netzwerk mit FreeNAS
    > und ZFS.
    > Ich habe 3x3GB (Seagate) und 3x1GB (WD Green) Platten verbaut.

    Vielleicht nimmst Du auch einfach einen (oder mehrere) USB Stick(s). Die gibts bereits mit weit(!) mehr als 4GB und vermutlich auch preiswerter als Festplatten.

    wερ δας λιεστ wιρδ δοοφ.

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

    Autor: ArcherV 11.10.17 - 17:03

    KarlaHungus schrieb:
    --------------------------------------------------------------------------------
    > ChriDDel schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Mein Microserver 40L schafft mehr als 90MB/s im 1GB/s Netzwerk mit
    > FreeNAS
    > > und ZFS.
    > > Ich habe 3x3GB (Seagate) und 3x1GB (WD Green) Platten verbaut.
    >
    > Vielleicht nimmst Du auch einfach einen (oder mehrere) USB Stick(s). Die
    > gibts bereits mit weit(!) mehr als 4GB und vermutlich auch preiswerter als
    > Festplatten.

    Vermutlich hat er sich vertippt und meint TB.

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

    Autor: Mixermachine 11.10.17 - 17:20

    ArcherV schrieb:
    --------------------------------------------------------------------------------
    > Mixermachine schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Soweit ich es verstanden habe, scannt ein neuer Controller gleich nach
    > > Platten und kann ein altes Raid 5 wieder einhängen.
    > > Der Controller muss natürlich vom gleichen Typ sein.
    >
    > Ja und genau das ist ja der Knackpunkt!
    > Wenn du einen gebrauchten gekauft hast, musst du dir erstmal einen neuen
    > und baugleichen Controller besorgen (oder gleich zwei gebrauchte kaufen und
    > hoffen, dass der andere überlebt).
    >

    Ich nehme an, dass die HP P410 die so verkauft werden alle gleich sind.
    Auf ebay gibt es da gerade 100+ Angebote (wird massig aus alten Servern ausgebaut). Denke ich kaufe mir demnächst mal einen als Backup :)

    > Den hick hack möchte ich mir im privaten Umfeld einfach nicht antun.
    >
    > Außerdem haben die Windows Storage Pools auch noch nette Features wie z.B.
    > Datendeduplizierung*.
    >

    Das ist tatsächlich etwas feines.
    Den nötigen RAM könnte ich allerdings nicht aufbringen (bei 6TB doch nicht zu unterschätzen).

    > * nur auf Windows Server / Storage Server, die Storage Pools selbst sind
    > hingegen auch im Windows ab Version 8 enthalten
    >
    > > und zusätzlich
    > > noch schwerer Abzusichern.
    >
    > Also das kann ich nicht so stehen lassen! Windows ist nicht per se
    > unsicherer als dein Debian oder Ubuntu.
    > Viel mehr hängt es doch vom persönlichen Know How ab. Arbeitsbedingt habe
    > ich sehr viel Erfahrung mit Windows, mir fällt es also recht einfach ein
    > Windows abzuhärten. Ein Debian Server hingegen? Da müsste ich mich erstmal
    > einlesen und würde bestimmt die ein oder andere Sachen übersehen. In meinem
    > Falle wäre der Debian Server also unsicherer.
    >

    Ich arbeite am Desktop auch zu 95% mit Windows, mir passiert nur meistens einfach zu viel bei Windows im Hintergrund. (zumindest für einen Server)
    Zusätzlich: wenn ich schon verschlüssele sollte die Software OpenSource sein.
    Verschlüsselung auf meinem Notebook traue ich nicht wirklich über dem Weg :/.
    Das mit dem Linux ging aber tatsächlich recht einfach.

    Minimale Debian Installation.
    LUKS Verschlüsselung einrichten. (3 Kommandozeilenbefehle)
    Mit Ext4 formatieren.
    2 Zeilen ins Script schreiben um das ganze nach einem Neustart zu mounten.

    Zusätzlich kommt noch Samba dazu (für die Windowsfreigabe).
    Aus der Erfahrung funktioniert die Freigabe aber fast besser als die Windowseigene.

    Alle paar Monate ein apt update & apt upgrade

    > Meine Webseiten laufen bis jetzt z.B. auch alle ohne Probleme auf einem
    > Windows Server ;).
    > Und ohne GUI geht ja auch, das ist also kein Argument.
    >
    > > So läuft jetzt eine Debian VM, die für alle anderen VMs auf dem Esxi und
    > im
    > > Netzwerk verschlüsselten Speicher bereitstellt.
    > > Da läuft sonst nichts anderes mehr.
    >
    > So ein ESXI ist ja schon eine schöne Spielerei, hatte ich mir des
    > Spaßeshalber auch mal aufgesetzt, die Single Lizenz ist ja kostenlos. Bin
    > dann aber doch HyperV genommen, ist für meine Zwecke deutlich sinnvoller
    > und auch komfortabler :)

    Stimmt, HyperV läuft mittlerweile auch rund, allerdings fehlt mir da das Webfrontend oder gibt's da mittlerweile etwas neues?

    Getter, Setter, Hashcode und Equals manuell testen in Java?
    Einfach automatisieren: https://github.com/Mixermachine/base-test



    1 mal bearbeitet, zuletzt am 11.10.17 17:30 durch Mixermachine.

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

    Autor: ArcherV 11.10.17 - 18:11

    Mixermachine schrieb:
    --------------------------------------------------------------------------------
    > Das ist tatsächlich etwas feines.
    > Den nötigen RAM könnte ich allerdings nicht aufbringen (bei 6TB doch nicht
    > zu unterschätzen).

    Meine NAS hat 16GB, bei 2x 3 TB und 3x 1TB hatte ich da bis jetzt noch keine Probleme.


    > Stimmt, HyperV läuft mittlerweile auch rund, allerdings fehlt mir da das
    > Webfrontend oder gibt's da mittlerweile etwas neues?

    AFAIK hat HyperV keine Weboberfläche. Der HyperV Manager ist aber ab Windows 7 bereits in Windows mitgeliefert, den muss man nur aktivieren.

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

    Autor: robinx999 11.10.17 - 20:04

    Nachträgliche Veränderungen sind bei anderen Systemen wie BTRFS aber auch Übel.
    Hatte bei meinem kleinen Minisystem eine einzelne 4TB Platte und habe eine Zweite eingebaut und habe es zu einem Raid 1 umgewandelt. ca. Halbvoll waren die Platten.

    Der Spass hat von Freitag Morgen Gedauert, Diesntag Abend war es nicht Fertig Mittwoch Früh war es fertig.
    Habe dann irgendwo einen Foreneintrag gefunden der vor solchen Änderung Warnt wenn man mehr wie 4 Snapshots hat (hatte 400, einen Pro Stunde erzeugen und bei mehr wie 400 immer den ältesten löschen)

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

    Autor: mhstar 11.10.17 - 20:37

    chr1z0r schrieb:
    --------------------------------------------------------------------------------
    > So ein Schwachsinn das es gefährlich wird.
    >
    > Ich selbst habe einen Pool aus 6 Spindeln a 2TB und benötigte mehr
    > Platz,...Also mussten 4TB Platten her.
    ...
    > 4.) Das bei allen 6 machen und zack hat man automatisch einen größeren Pool
    > mit 6x4TB - Z-Level

    Und die alten 6x 2TB Platten kommen auf den Mülllllll ;)))))))))))))))

    Super.

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

    Autor: mhstar 11.10.17 - 20:41

    > Habe dann irgendwo einen Foreneintrag gefunden der vor solchen Änderung

    Da sieht man aber auch, was das für ein Frickelzeug ist.
    Das gehört in die Doku, auf prominenter Stelle.

    Das gleiche mit ZFS und ashift. Wenn du das ashift nicht extra angibst und auf 12 setzt, wird das zpool mit einem ganz miesen ashift Wert angelegt (zu hoch macht wenig aus, zu niedrig und dein Pool wird später a****lahm). Natürlich kann man das nachträglich nicht ändern - eine Anfängerfalle.
    So was gehört auch in die Doku, ganz oben, und der Standardwert sollte besser gewählt werden.

    Bis das gemacht wurde ist das alles Frickelzeug.

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

    Autor: YarYar 11.10.17 - 22:02

    mhstar schrieb:
    --------------------------------------------------------------------------------
    > Das gleiche mit ZFS und ashift. Wenn du das ashift nicht extra angibst und
    > auf 12 setzt, wird das zpool mit einem ganz miesen ashift Wert angelegt (zu
    > hoch macht wenig aus, zu niedrig und dein Pool wird später a****lahm).
    > Natürlich kann man das nachträglich nicht ändern - eine Anfängerfalle.
    > So was gehört auch in die Doku, ganz oben, und der Standardwert sollte
    > besser gewählt werden.
    >
    > Bis das gemacht wurde ist das alles Frickelzeug.

    Welche Doku zu ZFS hast du denn gelesen? Das ashift Problem wird überall diskutiert. Das kann man gar nicht nicht mitbekommen. Und in den Tutorials und Dokumentationen die ich so gelesen habe steht das alles drin.

    Im übrigen: Wenn man ashift nicht angibt wird der Wert aus der Blockgröße bestimmt die die Festplatte zurückliefert. Bei älteren Platten gibt es da Probleme. Die liefern 512er Blockgröße zurück obwohl sie 4096er Blöcke haben. Dann macht zfs halt ashift=9 statt 12. Neuere Platten haben das Problem nicht.

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

    Autor: GAK 12.10.17 - 01:19

    YarYar schrieb:
    --------------------------------------------------------------------------------
    > Im übrigen: Wenn man ashift nicht angibt wird der Wert aus der Blockgröße
    > bestimmt die die Festplatte zurückliefert. Bei älteren Platten gibt es da
    > Probleme. Die liefern 512er Blockgröße zurück obwohl sie 4096er Blöcke
    > haben. Dann macht zfs halt ashift=9 statt 12. Neuere Platten haben das
    > Problem nicht.

    Bei Einsatz von neuer Software sollte man jedoch immer das Handbuch lesen.
    Es gibt für die 'lügenden' Laufwerke zwar inzwischen auch eine Lookup-Table, das manuell zu machen schadet jedoch nicht.

    Andere Vorteile von ZFS gegenüber klassischen Dateisystemen und RAID-Controllern wurde übrigens noch nicht genannt:
    - ZFS wird niemals* defekte Daten liefern da es alle Datenfehler erkennt (und automatisch behebt, solange ausreichend Redundanz da ist). Ein EXT mag vielleicht schneller von den Platten lesen können, reicht aber kommentarlos jeden Datenschrott den die Platten liefern an die Anwendung.
    - ZFS hat kein Problem bei über die Platten im Verbund verteilten Teildefekten (also auf jeder, aus welchen Gründen auch immer, ein paar Blöcke an unterschiedlichen Stellen korrupt sind) . Ein RAID(1/5)-Controller kann sowas weder erkennen noch sinnvoll reparieren und sobald man eine der Platten gegen eine frische tauscht werden die Fehler in ein dann angeblich gesundes Array repliziert (und ggf. intakte Daten zerstört).
    - Kein RAID Write-Hole wie bei klassischen Hardware-Controllern.
    - SSD basierter L2 Cache (L2ARC) möglich, transparent komprimiert.
    - SSD (oder battery backed RAM) ZIL (writeback-cache für synchrone Schreiboperationen) möglich.
    - Stressfreie und kostenarme Snapshots, systemübergreifende/inkrementelle Replikation dieser, schreibbare Clones.
    - Transparente On-Disk Kompression
    - On-Disk Deduplizierung**
    - Block-Devices (volumes, auch sparse) mit allen Features wie oben.

    Kommende Features auf die ich mich freue:
    - Verschlüsselte Datasets***.
    - General pool shrinking (ermöglicht das Entfernen von VDEVs und damit Verkleinerung/Strukturänderung eines bestehenden ZFS pools).

    * solange CPU und RAM ok sind
    ** ausreichend RAM ist vorteilhaft, sonst werden schreibzugriffe bitter langsam
    *** in Erprobung

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

    Autor: Floyddotnet 12.10.17 - 09:20

    YarYar schrieb:
    --------------------------------------------------------------------------------
    > Floyddotnet schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Falsch. In btrfs kann ich beliebg große platten einem pool dazufügen.
    > >
    > > Einfach mit:
    > > btrfs device add /neuesDevice /mnt
    > >
    > > Je nach RAID-Level und füllstand kann ein balance-lauf noch notwendig
    > sein
    > > um die datein neu zu verteilen:
    > >
    > > btrfs balance start /mnt
    >
    > Ja natürlich. Das geht auch mit mdadm. Aber du kannst von der größeren
    > Platte nur den Teil nutzen der mit den kleineren Platten überlappt. Der
    > Rest ist verschwendet. Insofern macht es keinen Sinn eine 2 TB in ein 10x
    > 1TB RAID zu hängen.

    Und genau das ist falsch. Ich hab selbst ein BTRFS-RAID aus 2x 3TB, 1x 6TB, 1x 8TB und kann die vollen 20 TB im RAID1-Profil nutzen.
    Ein BTRFS-RAID arbeitet ganz anders als ein HW-RAID, MDADM-RAID oder ZFS-RAIDZ. Und zwar werden bei BTRFS zuerst die Daten jenach RAID-Profil in Blöcke aufgeteilt die auf die Platten mit dem meißten freien Platz geschrieben werden.

    Für jedes RAID-Profil gibt es ein Profil welches aus folgenden 4 Parameter besteht:
    Copies, Min data stripes, Max data stripes, Parity stripes. Basierend auf diesem Profil verteilt der RAID-Code die Daten.

    für RAID1: Copies 2, Min data stripes 1, Max data stripes 1, Parity stripes 0
    für RAID5: Copies 1, Min data stripes 1, Max data stripes 100, Parity stripes 1
    für RAID6: Copies 1, Min data stripes 1, Max data stripes 100, Parity stripes 2
    ....

    Probier es ruhig hier aus: http://carfax.org.uk/btrfs-usage/

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

    Autor: YarYar 12.10.17 - 10:35

    Floyddotnet schrieb:
    --------------------------------------------------------------------------------
    > Und genau das ist falsch. Ich hab selbst ein BTRFS-RAID aus 2x 3TB, 1x 6TB,
    > 1x 8TB und kann die vollen 20 TB im RAID1-Profil nutzen.
    > Ein BTRFS-RAID arbeitet ganz anders als ein HW-RAID, MDADM-RAID oder
    > ZFS-RAIDZ. Und zwar werden bei BTRFS zuerst die Daten jenach RAID-Profil in
    > Blöcke aufgeteilt die auf die Platten mit dem meißten freien Platz
    > geschrieben werden.

    Also im vorliegende Beispiel mit einem RAIDZ/5 aus 10x 1 TB Platten kannst du auch mit btrfs nicht einfach ein 11te Platte mit 8 TB reinhängen und die vollen 8 TB nutzen. Das kann gar nicht funktionieren ohne die Redundanz zu verlieren weil für die parity nur 1 TB zur Verfügung steht.

    Dein Beispiel mit dem RAID1 funktioniert so weil es ein "mirror" ist und btrfs die Kopien geschickt verteilt. Zugegeben, das macht btrfs besser als ZFS oder mdadm. Aber auch hier gibt es Grenzen. Ein mirror aus einer 1 TB und einer 2 TB Platte kann auch unter btrfs nur 1 TB Nutzdaten speichern. Erst wenn eine dritte Platte mit 1 TB hinzukommt kann man 2 TB nutzen. Insofern hat btrfs bei RAID1 die Nase vorn. Aber nicht bei RAID5.

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

    Autor: HubertHans 12.10.17 - 11:20

    ArcherV schrieb:
    --------------------------------------------------------------------------------
    > Mixermachine schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ArcherV schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Mixermachine schrieb:
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > > -----
    > > > > Ich bin auch bei einem Raid 5 Controller geblieben.
    > > > > Mein Microserver N54L schafft es gerade so auf 120MB/s Durchsatz mit
    > > der
    > > > > Verschlüsselung AES 128.
    > > > > Über das Netzwerk sind es noch 80MB/s.
    > > > > Da bleibt kaum Luft für ein soft raid.
    > > >
    > > >
    > > > Die ~80 MB/s über Netzwerk schaffe ich auch mit softraid via Windows
    > > > Storage pools. - und bin dabei noch zum einen wesentlich flexibler und
    > > zum
    > > > anderen nicht auf einem teuren HW Controller angewiesen - wo man dann
    > > den
    > > > nassen Hut auf hat wenn er kaputt geht. Für mich im Privatumfeld
    > > deutlich
    > > > angenehmer.
    > >
    > >
    > > Auch mit Verschlüsselung?
    > > Ohne komme ich auch auf 300MB/s lesend :D.
    > > Ich verwende eine HP P410 Controller. Wenn man den RAM und die Batterie
    > > wiederverwenden kann, bekommt man einen Gebrauchten für 15 - 20 Euro ^^.
    >
    > Ne hab bitlocker noch nicht ausprobiert ^^
    >
    > Das Problem bei so einen gebrauchten Controller: wenn du zB ein RAID 5
    > nimmst und dir der Controller hochgeht hast du den nassen Hut auf..
    >

    Warum? Einfach einen aehnlichen Controller mit kompatibler Firmware bereit legen oder eben im Fehlerfall kaufen. No Problem. Es gibt eine Linux-Distribution, die viele dieser Datenstrukturen auch ohne Controller auslesen kann.

    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...

    Große Firmen nehmen dann einfach mehere Dateisserver und erzeugen so Redundanz, oder entsprechende Dateissystem werden wiederum von einem anstaendigen RAID-Controller in ein RAID5 oder RAID 6 gebunden um zumindest den Verlust von Stripes zu verhindern. Datenverlust bei Stromausfall kann man eh nicht zu 100% verhindern.

    > Wenn bei meinen Software RAID die Windows Installation hoch geht ist das
    > egal, ich geh einfach zum nächsten win 10 / Server 2016 Rechner und kann da
    > das RAID ganz normal öffnen.

    Wiegesagt, das geht bei einem HW-RAID ebenfalls, wenn man die entsprechend vorher getestete Software parat hat. Oder man ist so intelligent, einen Ersatz-Controller parat zu haben. Die meisten Modelle eines Herstellers sind ueber viele Jahre untereinander kompatibel. Teilweise Jahrzehnte.

    Softwareloesungen taugen als solche nicht fuer einen stabilen Betrieb. RAID-Controller mit HW-Unterstuetzung verfuegen ueber ECC Speicher und normalerweise auch ueber BBUs, wenn sie denn was taugen. Damit ist alles, was mit Parity zu tun hat, auf einem RAID-Controller besser aufgehoben. Softwareloesungen sind Spielkram. Bis sich eine Softwareloesung als Ausfallsicher betreiben laesst und dabei guenstig ist musst du schon mehrere Maschinen stehen haben. Fuer den Hausgebrauch Tuennes.

    >
    > Deswegen benutze ich meinen HW Controller nur noch als reinen SATA
    > Controller (ist ein alter gebrauchter von dell )

    Was dir jedoch Performanz kosten kann, da der Schreibcache des Betriebssystems fuer die dort angeschlossenen Laufwerke deaktiviert wird. Der Controller hat die Gewalt darueber und der Speicher ist begrenzt. Dafuer ist dann mehr RAM fuer das OS verfuegbar. Bedeutet: Der Controller bringt dir nur so lange etwas, wenn der Controller intern genuegend Ressourcen hat, um mit dem Host mitzuhalten.



    2 mal bearbeitet, zuletzt am 12.10.17 11:24 durch HubertHans.

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

    Autor: bccc1 12.10.17 - 11:50

    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.
    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.

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

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

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

    Autor: Sinnfrei 12.10.17 - 13:26

    Falsche Planung ist aber nicht ein Problem des Dateisystems. Was geht, und wie es geht, steht alles in der Doku:

    https://docs.oracle.com/cd/E18752_01/html/819-5461/gavwn.html

    __________________
    ...

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

    Autor: pumok 12.10.17 - 16:19

    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.
    Aber deswegen solche Unwahrheiten zu erzählen, finde ich persönlich schwach.

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

    Autor: tingelchen 12.10.17 - 16:42

    > RAID war mir persönlich aber auch nicht das Optimum, da hier die Kapazität auch nur
    > kostenintensiv erweitert werden kann.
    >
    Das ist so pauschal nicht richtig. Es kommt natürlich darauf an ob man noch Plätze frei hat. Ich habe in meinem NAS ein 3ware Raid Controller. Da habe ich dann einfach 2 Platten dazu gesteckt und das bestehende Array erweitert. Der Migrationsprozess hat zwar mehrere Tage gedauert, aber spielte keine Rolle, da das Array uneingeschränkt nutzbar war.

    Folglich beliefen sich die Kosten nur auf die 2 neuen Platten. Um die man ja nicht herum kommt :)

    Ob es also Kostenintensiv wird, oder nicht, ist sehr spezifisch.

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

    Autor: tingelchen 12.10.17 - 16:55

    Aus diesem Grund bin ich davon ab einen Rechner als Storage System zu betrachten. Ich betrachte diesen nur noch als Teilmenge eines Storage Systems und spanne dieses dann über mehrere Nodes auf. Geht mir der Platz aus, muss man weder alte voll funktionsfähige Platten weg werfen, noch irgendwie am FS herum fummeln. Einfach einen Node dazu hängen, fertig.

    Das ist nicht die preiswerteste Lösung. Aber die flexibelste.

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

    Autor: robinx999 12.10.17 - 20:06

    Floyddotnet schrieb:
    --------------------------------------------------------------------------------
    > YarYar schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Floyddotnet schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Falsch. In btrfs kann ich beliebg große platten einem pool dazufügen.
    > > >
    > > > Einfach mit:
    > > > btrfs device add /neuesDevice /mnt
    > > >
    > > > Je nach RAID-Level und füllstand kann ein balance-lauf noch notwendig
    > > sein
    > > > um die datein neu zu verteilen:
    > > >
    > > > btrfs balance start /mnt
    > >
    > > Ja natürlich. Das geht auch mit mdadm. Aber du kannst von der größeren
    > > Platte nur den Teil nutzen der mit den kleineren Platten überlappt. Der
    > > Rest ist verschwendet. Insofern macht es keinen Sinn eine 2 TB in ein
    > 10x
    > > 1TB RAID zu hängen.
    >
    > Und genau das ist falsch. Ich hab selbst ein BTRFS-RAID aus 2x 3TB, 1x 6TB,
    > 1x 8TB und kann die vollen 20 TB im RAID1-Profil nutzen.
    > Ein BTRFS-RAID arbeitet ganz anders als ein HW-RAID, MDADM-RAID oder
    > ZFS-RAIDZ. Und zwar werden bei BTRFS zuerst die Daten jenach RAID-Profil in
    > Blöcke aufgeteilt die auf die Platten mit dem meißten freien Platz
    > geschrieben werden.
    >
    Ja BTRFS ist da um einiges Cleverer wobei man es mit MDADM auch machen könnte aber das wäre natürlich relativ großer Aufwand und sicher könnte man in dem oben genannten Beispiel auch nur 18 TB sinvoll in ein Raid Bekommen: 6TB + 3 TB JBOD und 8 TB +1TB (von der 3 TB Platte) ebenfalls als JBOD und die beiden JBODs zu einem RAID 1 Zusammenfassen. Wobei ich noch überlege ob man die 2 TB die von von der 3 TV Festplatte zur Verfügung stehen so in ein JBOD zusammenfassen kann, dass sie beim ersten am Anfang sind und beim zweiten am Ende so dass man das auch noch ins Raid1 bringen könnte und die volle Kapazität nutzen könnte

  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. Würth Elektronik eiSos GmbH & Co. KG, Waldenburg
  2. Techniker Krankenkasse, Hamburg
  3. ARNOLD IT Systems GmbH & Co. KG, Freiburg
  4. Deutsche Rentenversicherung Rheinland, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Energiewende: Schafft endlich das Brennstoffzellenauto ab!
Energiewende
Schafft endlich das Brennstoffzellenauto ab!

Sie sind teurer und leistungsschwächer als E-Autos und brauchen dreimal so viel Strom. Der Akku hat gewonnen. Wasserstoff sollte für Chemie benutzt werden.
Ein IMHO von Frank Wunderlich-Pfeiffer

  1. Hyundai Nexo Wasserdampf im Rückspiegel
  2. Brennstoffzellenauto Bayern will 100 Wasserstofftankstellen bauen
  3. Elektromobilität Daimler und Volvo wollen Brennstoffzellen für Lkw entwickeln

Materiejets aus schwarzem Loch: Schneller als das Licht?
Materiejets aus schwarzem Loch
Schneller als das Licht?

Das schwarze Loch stößt Materie mit einer Geschwindigkeit aus, die wie Überlichtgeschwindigkeit aussieht.
Ein Bericht von Andreas Lutter

  1. Oumuamua Ein ganz normal merkwürdiger interstellarer Asteroid

Außerirdische Intelligenz: Warum haben wir noch keine Aliens gefunden?
Außerirdische Intelligenz
Warum haben wir noch keine Aliens gefunden?

Seit Jahrzehnten gucken wir mit Teleskopen tief ins All. Außerirdische haben wir zwar bisher nicht entdeckt, das ist aber kein Grund, an ihrer Existenz zu zweifeln.
Von Miroslav Stimac