• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

zfs mirror - auch mit nur einer Festplatte?

H

holgerw

Guest
Themenstarter #1
Hallo,

ich habe mich nun mit zfs ein wenig intensiver befasst und möchte dieses Dateisystem standardmäßig einsetzen.

Wie ich laut Dokumentation weiß, hat zfs die gleiche Performanz auf vorformatierten wie nicht formatierten Festplatten.
Man kann einen Pool anlegen ohne Spiegelung oder gar Raid-Funktionalität, verspielt dann aber einige tolle Features, wenn es um das Reparieren von Dateninkonsistenzen geht.

Meine Überlegung: Hat man nur eine ssd, und möchte trotzdem einen Pool auf Redundanz anlegen, kann man dann nicht auf dieser ssd zwei gleich große Partitionern erzeugen und dann folgendes machen:
Code:
zpool create poolssd0 mirror /dev/ada0p1 /dev/ada0p2
Mir geht es hier nicht um einern Schutz gegenüber einem Festplattenausfall, dazu brauch man einen pool auf einem raid-z mit mindestens drei Platten. Auch ein Backup persönlicher Daten fällt beim Einsatz von zfs, ob nun mit oder ohne Spiegelung, nicht unter den Tisch. Mir geht es darum (siehe FreeBSD-Handbuch - zfs Administration):
Ein Pool mit nur einer einzigen Platte besitzt keine Redundanz. Datenverfälschung kann erkannt, aber nicht repariert werden, weil es keine weiteren Kopien der Daten gibt. Die Eigenschaft copies kann genutzt werden, um einen geringen Fehler wie einen beschädigtem Sektor auszumerzen, enthält aber nicht die gleiche Art von Schutz, die Spiegelung oder RAID-Z bieten.
Wenigstens auf Spiegelung mag ich - wenn ich schon zfs auf dem Desktop nutze - nicht verzichten.

Meine Fragen:
Geht das?
Wenn das geht: Bremst das die Performanz stark aus?

Viele Grüße,
Holger
 
H

holgerw

Guest
Themenstarter #3
Klaro geht das, einfach zwei Partitionen anlegen und den Pool daraus bauen.
Der Nutzen erschließt sich mir aber nicht.
Rob
Hallo Rob,

wenn ich den oben zitiereten Handbuchausschnitt richtig verstehe, würde ein
Code:
zpool create poolname /dev/ada0
einen nicht-redundanten Pool erstellen, bei dem zwar
Datenverfälschung erkannt, aber nicht repariert werden kann, weil es keine weiteren Kopien der Daten gibt.
Habe ich hingegen auf ada0 zwei gleichgroße Partitionen und erstelle einen Pool auf ada0p1 und seinen Spiegel auf ada0p2, dann kann bei Datenverfälschung repariert werden.

Darin sehe ich den Nutzen.

Viele Grüße,
Holger
 

-Nuke-

Well-Known Member
#5
Prinzipiell würde das wohl gehen. Hab es natürlich nie getestet. Du halbierst dir damit nur die SSD-Performance beim Schreiben, da alle Daten doppelt geschrieben werden. Und natürlich halbierst du dir damit auch den verfügbaren Speicher.

Ich würde eher sagen, die Nachteile überwiegen hierbei den Vorteilen. Gerade bei SSDs ist es eher so (mal von TRIM-Bugs in der Firmware abgesehen), dass vermutlich eher die komplette SSD sterben wird, als nur Teile davon. Außer die lässt die SSD über Wochen und Monate ohne Strom, dann verlieren sie wohl auch zufällig Daten.
 

MuffiXXL

Well-Known Member
#6
Habe ich hingegen auf ada0 zwei gleichgroße Partitionen und erstelle einen Pool auf ada0p1 und seinen Spiegel auf ada0p2, dann kann bei Datenverfälschung repariert werden.
Hallo holgerw. ich sehe mit diesem Ansatz aber ein paar Probleme, die man mal gegeneinander gewichten sollte. ZFS Bildet Checksummen, somit werden Datenverfälschungen so oder so erkannt. Dazu brauchst du also keine Spiegelung, aber so viel Scheint klar zu sein. Da ZFS weiterhin Konzeptuell auf COW aufsetzt kann ZFS dieses auch schon mit einer Platte schon ein Stück weit einsetzen um Korrupte Blöcke zu reparieren. Dies trifft aber wahrscheinlich nur auf einen kleinen Teil der Daten zu die man so rumliegen hat.
Setzt du nun einen RAID über die gleiche Platte auf, bist du gegen Sektorenfehler ein Stück weit geschützt, aber du verdoppelst die Last auf dem Device - aus doppelter Belastung folgen halbierter Durchsatz und reduzierte Lebensdauer. Du würdest dir also die größere Datensicherheit durch niedrigere Bandbreite und (bei einer SSD kann man das ja wirklich so sagen) halbierte Lebenszeit des Geräts erkaufen. Dabei erhöhst du vermutlich auch die Gefahr kaputte Sektoren rein zu bekommen signifikant.

Lange Rede kurzer Sinn: Ich glaube, die Idee, die du da hast ist eher Kontraproduktiv, da du dir Datensicherheit erkaufen willst indem du die zugrunde Liegende Hardware doppelt so viel stresst. Das kann imo nicht gut gehen.
 
H

holgerw

Guest
Themenstarter #8
Hallo,

wow, was für eine Beteiligung mit so vielen Tipps, danke :)

Aber warum sollen denn Datenverfälschungen auftreten?
Ich find das ein wenig zu paranoid.
Rob, was die Verfälschungen angeht, bitte nicht falsch verstehen, das ist nicht meine Auffassung sondern ein Zitat aus dem Handbuch (und damit sind wohl auch weitere Inkonsistenzen gemeint).

Da ZFS weiterhin Konzeptuell auf COW aufsetzt kann ZFS dieses auch schon mit einer Platte schon ein Stück weit einsetzen um Korrupte Blöcke zu reparieren.
Gut, also ist auch ein Pool ohne Spiegelung schon gegen manches gefeit.

Ich glaube, die Idee, die du da hast ist eher Kontraproduktiv, da du dir Datensicherheit erkaufen willst indem du die zugrunde Liegende
Hardware doppelt so viel stresst. Das kann imo nicht gut gehen.
Du halbierst dir damit nur die SSD-Performance beim Schreiben, da alle Daten doppelt geschrieben werden. Und natürlich halbierst du dir damit auch den verfügbaren Speicher.
Dann lasse ich das, das leuchtet mir ein.

Wenn also Spiegelung, wäre es besser, bei zwei verbauten SSDs zwei gleichgroße Partitionen ada0px und ada1px zu erzeugen und darauf dann einern Pool mit Mirror zu kreieren, oder aber zwei gleichgroße SSDs zu verbauen und dann zu spiegeln.

Viele Grüße,
Holger
 

mipl

Well-Known Member
#9
Holger,
Du kannst die Vorteile der ZFS-Datenredundanz und damit die Möglichkeit, kaputte Daten automatisch zu reparieren, auch auf einer einzigen Platte/SSD nutzen. Ich mache das manchmal mit meinem /home/mipl/Dokumente-Verzeichnis auf Notebooks. Der Trick: Multiple Copies. Im Grunde legst Du dann für bestimmte Verzeichnisse (oder Volumes) einfach mehrere Kopien der (Meta-)Daten an:

zpool create tank ada0
zfs create -o copies=2 tank/DokuMirror
zfs get copies tank/DokuMirror

NAME PROPERTY VALUE SOURCE
tank/DokuMirror copies 2 local

Üblicherweise ist copies=1 für ZFS-Volumes. Das linke ich mir dann ins /home.

Siehe man-page zu zfs:
[...]
copies=1 | 2 | 3
Controls the number of copies of data stored for this dataset. These
copies are in addition to any redundancy provided by the pool, for
example, mirroring or RAID-Z. The copies are stored on different
disks, if possible. The space used by multiple copies is charged to
the associated file and dataset, changing the used property and
counting against quotas and reservations.

Changing this property only affects newly-written data. Therefore,
set this property at file system creation time by using the -o
copies=
N option.

Viele Grüße
Michael

Edit: Hier mehr Infos: https://blogs.oracle.com/relling/entry/zfs_copies_and_data_protection
 
H

holgerw

Guest
Themenstarter #10
Hallo Michael,

danke für diesen Tipp. Dazu noch zum Verständnis folgende Frage:

Angenommen, ich habe
ssdpool1 (Pool) darin /daten (Dataset) darin /proudiere (Ordner), /home (Ordner)

Geht dann auch
Code:
zfs create -o copies=2 ssd0pool/daten/home
also, eine ordnerbezogene Zuweisung von mehreren Kopien? Oder muss diese Zuweisung Dataset-bezogen sein?

Sorry, dass ich so penetrant detailliert nachfrage, ich möchte in meiner Installations-Dokumentation (und zu zfs wird es ein Kapitel geben) keinen Schrott schreiben.

Viele Grüße,
Holger
 

kira12

Well-Known Member
#11
Mir geht es hier nicht um einern Schutz gegenüber einem Festplattenausfall ... Auch ein Backup persönlicher Daten fällt beim Einsatz von zfs, ob nun mit oder ohne Spiegelung, nicht unter den Tisch.
Hallo Holger,

ich hoffe das ich das nicht falsch lese. Aber ein Duplikat deiner Daten ersetzt kein Backup! las dich mal Daten löschen oder eine Software löscht daten, dann sind diese auch auf den Duplikaten weg. Im Backup sind Sie noch gefangen...

Gruß ré
 
H

holgerw

Guest
Themenstarter #12
Hallo Holger,

ich hoffe das ich das nicht falsch lese. Aber ein Duplikat deiner Daten ersetzt kein Backup! las dich mal Daten löschen oder eine Software löscht daten, dann sind diese auch auf den Duplikaten weg. Im Backup sind Sie noch gefangen...

Gruß ré
Hallo Kira,

das liest Du nicht falsch, mir ist klar: Auch zfs ist kein Ersatz für ein Backup auf einer anderen Maschine.
Aber danke, dass Du nochmal drauf hin weist. :)
 

mipl

Well-Known Member
#14
Hallo Holger,
die Anzahl der Kopien lässt sich nur Dataset-bezogen einstellen, auf ein Verzeichnis angewendet gibt das ein "cannot open 'tank/<Verzeichnis>': dataset does not exist".

Zum Thema Backup/Sinn von Mirror auf einer SSD/etc.: Aus dem Bauch heraus geschätzt (und irgendwo mal ähnlich gelesen) stellen kaputte Sektoren rund die Hälfte der Festplattenfehler dar. Die Platte funktioniert ansonsten noch. Hier würde ein Mirror auf ein einziges Device oder die copies=2|3-Einstellung also helfen. Ich verwende das manchmal für kleine und wenig performance-relevante Daten... also beispielsweise Texte. Auch für eine FreeBSD-Installation selbst könnte das brauchbar sein, weil hier nur sehr selten Daten geschrieben werden. Für /tmp oder Download-Verzeichnisse und alles, bei dem viel und oft geschrieben wird, würde ich zwei Devices als Mirror klar vorziehen.

Multiple Copies schützen also nur vor dem insgesamt seltenen Fall, dass Sektoren wegbrechen und man das erkennen und(!) on-the-fly reparieren können will. Gegen Plattenausfälle hilft ein Mirror, gegen versehentliches Löschen helfen Snapshots, für all dies und(!) alles andere nur Backups.

Viele Grüße
Michael
 
H

holgerw

Guest
Themenstarter #16
Hallo Michael,

danke Dir.

Aus dem Threadverlauf habe bis jetzt unter anderem gelernt:
- zfs Optionen wie copies oder compression sind Dataset-bezogen
- auch zfs mit diversen Optionen macht ein Backup nicht überflüssig
- mirror besser mit verschiedenen Platten betreiben

Aber dafür, dass zfs so mächtig ist, finde ich es für Leute im Anfängerstadium erstaunlich überschaubar und gut lernbar.

Viele Grüße,
Holger
 

pit234a

Well-Known Member
#17
Beinahe traue ich mich nicht, danach zu fragen, aber, wer hat denn das jemals auf einem Desktop gebraucht?

Die Frage ist natürlich bei einem Fileserver eine ganz andere und da hat man dann mehrere Platten und braucht Redundanz.

Wenn ich von einem typischen Desktop-PC spreche, dann hat der eine Festplatte, ein Betriebssystem mit einem Desktop-Environment und einigen zusätzlichen Programmen. Es ist der Typ Rechner, den ich überwiegend seit etwa 20 Jahren nutze und in der ganzen Zeit hatte ich nicht eine einzige Inkonsistenz, die nicht durch fsck beseitigt werden konnte und zwar auch schon auf EXT2 und UFS (quasi UFS1 aber auch der Version von SUN), also non-journaling Dateisystemen.

Es ist doch so: ein Betriebssystem habe ich sehr schnell wieder aufgebaut. Es genügt meist sogar ein einfaches Live-System auf einem Stick (etwa Knoppix), um einen PC wieder zu booten. Daten, die ich brauche, habe ich doch gesichert, bzw, ich trage die doch eh mit mir rum, weil ich die nicht auf einem PC alleine bearbeite und liegen lasse. Was wichtig ist, gehört nicht auf einen PC.
Deshalb darf eine Festplatte in einem Desktop-PC jederzeit abrauchen. Dieses Szenario muss ich in meinen Umgang mit wichtigen Daten eingearbeitet haben und stets berücksichtigen. Und zwar vollkommen unabhängig von verwendeten Dateisystemen.

Eine "Datenverfälschung" kann ich mir nicht erklären. Der Begriff erschließt sich mir nicht. Immerhin bietet ZFS noch nicht mal eine Art fsck an, weil es davon ausgeht, dass seine Daten immer konsistent sind. Werden diese Daten nun über mehrere Geräte (in einem Pool) verteilt, so ist das doch immer noch nur ein Datensatz (eben mit zusätzlichen Daten, die eine Wiederherstellung erlauben, wenn ein oder mehrere Geräte ausfallen). Es ist doch ZFS ziemlich egal, auf wie vielen Geräten es liegt. Anders gesagt, ob eine "Datenverfälschung" (was immer das ist) im Dateisystem auftritt, ist doch nicht abhängig von der Anzahl der eingesetzten Geräte innerhalb eines Pools. Und wenn diese "Datenverfälschung" auftritt, kann sie doch bestenfalls mit einer externen Kopie des Datensatzes (snapshot...) repariert werden. Das scheint mir ein Widerspruch in sich zu sein.
Deshalb verstehe ich hier "Datenverfälschung" eher als "Verlust eines Datenträgers", wobei "Verlust" eine Beschädigung einschließt, die Fehler verursacht und als Datenträger verstehe ich dann die Geräte (evtl auch Partitionen) im Pool. Andernfalls scheint mir die Aussage doch irgendwie komisch.
 

-Nuke-

Well-Known Member
#18
Eine "Datenverfälschung" kann ich mir nicht erklären.
Bitflip, Bitrot...

Du speicherst 11111111, und plötzlich, durch Strahlung, kleiner Headcrash, Lesefehler oder was auch immer, wird daraus 11111101 oder 11110011. Je nachdem was das für ein Bereich nun war, könnte die ganze Datei oder auch der ganze Ordner weg sein. Und ZFS bietet halt kein fsck an, weil es im Prinzip bei jedem Zugriff ein "fsck" auf diesen Bereich fährt, indem er die Checksummen mit den Daten vergleicht und im Fehlerfall eine Reparatur einleitet.

Das Problem dieses Argument mit Backups oder Snapshots wegzureden ist nicht zielführend. Ohne dir die Daten anzusehen, kannst du gar nicht beurteilen ob die Daten nun korrekt sind der nicht. D.h. auch dein Backup wird über kurz oder lang diese defekte Datei enthalten, da du das Backup ja nicht ewig aufheben kannst.

ZFS verhindert das nun aktiv. Ob man es nun auf einem Desktop braucht ist natürlich fraglich. Man könnte natürlich auch über NFS auf einem anderen PC die Daten lagern. So mache ich das halt.
 
R

ralli

Guest
Themenstarter #19
Dieses Thema oder diese Frage ist nun wirklich nicht mehr neu und wurde schon vor 6 Jahren hier im Forum lebendig diskutiert:
http://www.bsdforen.de/threads/entscheidung-zwischen-ufs-und-zfs.24881/
Hat sich seitdem eigentlich grundlegend was geändert? Das interessiert mich nämlich. Ich habe zwar auf meinem Desktop System auch FreeBSD 10.3 mit ZFS installiert, aber mittlerweile sehe ich, nachdem ich den damaligen Thread gelesene habe, keine wirklichen Vorteile mehr für den normalen Nutzer mit einer HD. Außer das ich mein RAM verbrate .....
Auch würde mich in diesem Zusammenhang folgendes Szenarium interessieren:
Schützt mich ZFS zuverlässig auch dann vor einem drohenden Datenverlust, wenn die HD dem Ende entgegenstrebt? Werde ich gewarnt? Kann ich dann noch Daten retten, oder ist das, wenn überhaupt, extrem aufwendig?
 

mipl

Well-Known Member
#20
Eine "Datenverfälschung" kann ich mir nicht erklären. Der Begriff erschließt sich mir nicht.
Nimm mal ein ext4/xfs/btrfs, hänge das Dateisystem aus, mache per Sektoreditor in einem Text aus einem "X" ein "U" und mount es wieder. Es gibt keine Fehlermeldung. Machst Du dasselbe mit ZFS, gibt es hingegen eine Fehlermeldung.
Bei einem herkömmlichen RAID-Mirror werden Daten abwechselnd von Geräten gelesen. Erkennt eine Platte einen Lesefehler, wird statt dessen von einer anderen Platte gelesen. Erkennt eine Platte einen Lesefehler NICHT, bekommst Du das nicht mit. Und selbst, wenn Du es prüfen würdest, hättest Du zwei unterschiedliche Sektoren an derselben Stelle auf den Platten - aber welcher der korrekte ist, kannst Du nur raten.
ZFS erkennt den Fehler, auch wenn die Platte keinen Fehler meldet, list den korrekten Sektor von einer anderen Platte und korrigiert den Fehler auf der ersten Platte - das ist die sogenannte Selbstheilung, die automatisch beim Lesen stattfindet (oder per "scrub" angeworfen werden kann).
Einmal geschrieben Daten sind ale grundsätzlich bis aufs letzte Bit immer korrekt - oder eben komplett weg, wenn es das ganze Storage zerreißt. Es gibt niemals eine Datei, die nicht dem Zustand entspricht, in dem sie geschrieben wurde.

Immerhin bietet ZFS noch nicht mal eine Art fsck an, weil es davon ausgeht, dass seine Daten immer konsistent sind.
ZFS braucht kein fsck. Wenn Daten geschrieben werden, wird eine Checksumme gebildet, die in dem darüberliegenden Knoten der Metadaten gespeichert wird. Die Checksumme dieses Knotens wird im darüberliegen Knoten gespeichert... und so weiter... bis zum Masterblock (eigentlich: "Überblock"). Der enthält die Checksumme des darunterliegen Knotens und die von sich selbst. Es wird also "von unten nach oben" geschrieben und immer eine Checksumme gebildet.
Nun ist ZFS ein Copy-on-Write-System, überschreibt Blöcke also nicht, sondern schreibt veränderte Blöcke immer an eine andere Stelle. Knipst Du beim Schreiben den Strom aus, findet ZFS beim nächsten Starten den "alten" Masterblock und darunter eine korrekte und durch Checksummen bestätigte Datenstruktur. Die teilweise geschrieben Daten und Knoten hängen irgendwo in der Luft und interessieren ZFS nicht.
Der Masterblock ist viermal vorhanden, zweimal am Anfang, zweimal am Ende eines Datenträgers. Dazu wird er in einem Ringspeicher mit 128 Speicherplätzen verwaltet. Es gibt also immer bis zu 127 "vorherige" Masterblöcke. Der aktuelle masterblock ist der neueste, bei dem auch seine eigene Checksumme stimmt - das ist also alles, was bei ZFS einem fsck entsprechen würde: Suche den neuesten korrekten Masterblock. Alles andere passt automatisch.
Übrigens: ZFS benutzt Datenblöcke variabler Größe, der Overhead für die Metadaten liegt dadurch bei rund 1% - wie bei anderen Dateisystemen auch. Der Rechenaufwand ist auf modernen Xeons vernachlässigbar - im Gegenteil, mit SSD-Caches, reichlich Spindeln und RAM satt ist ZFS sogar schneller als andere Dateisysteme.

In 30 Jahren IT und 25 Jahren Autorentätigkeit ist mir genau einmal ein Text auf Grund eines Platten-Lesefehlers kaputtgegangen. Den konnte ich mit einem Sektoreditor teilweise retten, wobei ich wegen des Textsalats seitdem kein OpenOffice sondern gedit und ASCII-Texte verfasse. ;) Mit ZFS wäre das nicht passiert, was nun kein schlagendes Argument ist, gebe ich zu.
Aaaaber: Ich habe vor langer Zeit beispielsweise meine für die Steuern relevanten Daten, Dokumentationen, Bücher, Fotos und so weiter auf ZFS abgelegt, und das mehrfach. Da kann ich mir SICHER sein, dass die auch in Zukunft sauber lesbar sind. Ich habe etliche Bilder von "CDR-Backups" und auf alten ext2-Festplatten, die kaputt sind. Erst seitdem ich auf ZFS speichere, WEISS ich, dass sich nichts mehr verändern kann.

Und wie oben angegeben, lege ich mir manchmal für wichtige Dinge auch auf einem Notebook mit nur einer Platte ein Dataset mit copies=2 an, nur um ruhiger schlafen zu können.

Irgendwo gab es eine Statistik, dass Platten heute ab 7 TByte mindestens einen nicht erkennten Bitfehler ins Dateissystem weiterreichen... und nur ZFS kann das erkennen. Da ich ansonsten ZFS mag und keine Nachteile empfinde, ist es für mich alternativlos. Schade, dass OpenBSD ohne auskommen muss... aber die meiste Zeit liegen Texte oder Code sowieso auf einem Server mit ZFS - also macht das im Endeffekt nichts aus. Und so paranoid, dass ich mal am Wochenede mit einem OpenBSD-Notebook vor lauter Angst vor Bitrotting oder querschießenden Alpha-Teilchen nicht schlafen kann, bin ich noch nicht :D

Tipp: Guck Dir mal das hier an, ist lang, aber danach versteht man ZFS wirklich:

Viele Grüße
Michael
 
R

ralli

Guest
Themenstarter #21
Oh Michael, Du warst schneller.... Danke für Deinen sehr lehrreichen Beitrag, der mir geholfen hat, auch bei meiner alten Möhre bei ZFS zu bleiben. Auf Schnelligkeit kommt es bei mir eh nicht an, die Stabilität und Datensicherheit indessen ist mir schon wichtig, da ich viel in den letzeten 20 Jahren schriftstellerisch unterwegs war und ein dauerhafter Datenverlust einer Katastrophe gleich käme. Allerdings verlasse ich mich dabei auch nicht auf ZFS alleine, sondern sichere meine Daten auf verschiedenen Datenträgern und außerdem in einer Cloud. Mehr Vorsorge geht wohl nicht. Eine paranoide Veranlagung habe ich ebenfalls nicht, aber oberflächlich bin ich auch nicht. Und nun werde ich mir das Video ansehen.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#22
rgendwo gab es eine Statistik, dass Platten heute ab 7 TByte mindestens einen nicht erkennten Bitfehler ins Dateissystem weiterreichen...
Naja, die meisten Billig-Festplatten liegen derzeit bei laut Hersteller einem unkorrigierbaren Lesefehler in 10^14 Bits. Das sind grob ein Fehler alle ~11,6TiB. Bei modernen 8TiB Platten muss man die Festplatte also nur 1,375 Mal auslesen und schon hat man das erste nicht erkannte Problem. Nun muss man aber annehmen, dass der Hersteller bei seinen Angaben eher optimistisch ist und sei es nur, da er von einer optimalen Betriebsumgebung ausgeht. Hinter Festplatte kommen noch Kabel, der Controller, das Mainboard, der RAM, die CPU... Alles potentielle Fehlerquellen. So gesehen erscheinen die 7TiB schon realistisch, wenn nicht sogar etwas zu hoch.
 
H

holgerw

Guest
Themenstarter #23
Beinahe traue ich mich nicht, danach zu fragen, aber, wer hat denn das jemals auf einem Desktop gebraucht?
Hallo Pit,

doch, bitte traue Dich, so etwas zu fragen. Da kommt doch sehr Lehrreiches dabei heraus, wenn ich dazu hier die Antworten lese. Allerdings gebe ich zu: Diese Frage hätte ich etwas anders gestellt, nämlich: Was findest Du interessant an zfs, dass Du es nun auf Deinem Desktop-System einsetzen möchtest?

Und nun möchte ich mal - als Anfänger - etwas dazu sagen:

Anfangs war ich nach Erlebnissen mit schlechter Performance bei PC-BSD eher zfs-Gegner für Desktop-Systeme. Dann gab es aber hier einige spannende Kommentare zu zfs, den Konfigurationsmöglichkeiten, und auch einen ram-sparsamen Betrieb. Da bekam ich schon den Eindruck, zfs doch ein wenig falsch eingeschätzt zu haben.
Dann gab es in einem anderen Thread von mir eine Diskussion zu portmaster versus poudriere, und eigentlich ist @-Nuke- schuld :D, der hat bei poudriere irgendwie so eine überzeugende Art. (poudriere ist übrigens auch gut für Leute ohne große Vorkenntnisse ohne großen Lernaufwand ordentlich zu händeln, man muss meines Erachtens nur den Schweinehund überwinden, und sich mal für eine Stunde gründlich die gute Doku durchlesen und sich bei Bedarf hier trauen, Fragen zu stellen, dann klappt das auch mit poudriere). Und in der Doku taucht auch auf, poudriere auf einerm zfs Dataset zu benutzen (ufs2 geht wohl auch, scheint aber nicht erste Wahl zu sein). Wegen plasma5 habe ich entschieden, mir poudriere aufzusetzen und das auch zu dokumentieren in meiner Anleitung FreeBSD auf dem Desktop.
Dann habe ich mal heute früh auf der Zugfahrt zum hr damit begonnen, mir zu zfs die Doku durch zu lesen, dazu gibt es ein Handbuch von Oracle für Solaris und auch diverse Kapitel im FreeBSD-Handbuch. Was mir gefällt:
- zfs ist sehr mächtig aber überschaubar (ein Anfänger kommt mit dem, was man so braucht für den eher einfachen Betrieb auf dem Desktop-System sehr schnell mit den Werrkzeugen klar, ohne tagelang Doku wälzen zu müssen)
- mit zfs Datasets hat man sich quasi als Nebeneffekt mal gerade eben etwas wie lvm eingerichtet (das finde ich unter GNU/Linux deutlich komplexer)
- sehr flexibel (verschiedene Datasets mit verschiedenen Optionen)
- ein Pool ist rasch erweiterbar
- im Vergleich zum Umgang mit traditionellen Partitionen finde ich zfs wesentlich einfacher (ich glaube, wer beides nicht kennt, wird mit der grundlegenden Struktur bei zfs rascher klar kommen)*

* Anmerkung: Ich rede hier nicht vom Betrieb im Hochverfügbarkeitsbereich (rgroße Server im professionellen Umfeld), da gibt es sicherlich sehr umfangreiche Literatur zu zfs).

Viele Grüße,
Holger
 
R

ralli

Guest
Themenstarter #24
So @mipl, das Video war sehr informativ, danke nochmals dafür. In Verbindung mit den vorgenannten Handbüchern von FreeBSD und Oracle eine solide Grundlage. Bei Oracle bin ich mir nicht ganz sicher, ob die auch für FreeBSD gültig sind, denn die dürften sicherlich einen etwas anderen Entwicklungsstand haben. Jetzt aber heißt es die Kluft zwischen Theorie und Praxis zu schließen und mit ZFS ein wenig rum zu spielen und alles auszuprobieren, was man zukünftig davon verwenden möchte.
 

pit234a

Well-Known Member
#25
Für die umfassenden und wirklich verständlichen Erklärungen möchte ich mich auch bedanken und das Video kommt nach der Fußball-EM dann auch auf meinen Plan.

Nur um das nochmal deutlich zu machen: ich bin so etwas wie ein ZFS-Fan der ersten Stunde. Naja, das ist etwas übertrieben, aber schon seit FreeBSD 7er Zeiten nutze ich sehr gerne ZFS und habe es sehr lieb gewonnen. Zuvor hatte ich etliche Dateisysteme immer wieder probiert und war im Grunde bis zu meinem Wechsel zu FreeBSD mit XFS verbandelt. Weil es das nicht für FreeBSD gab, lernte ich mit UFS zu leben und es zu schätzen, was bis heute anhält.

Was ich nicht wusste war, dass das Verhalten hinsichtlich der Selbstheilung ein anderes ist, wenn ich einen Mirror oder ein Raid aufsetze. Ich war der Meinung, dass innerhalb jedes Datasets die Mechanismen zur Selbstheilung über entsprechende Prüfsummen greifen, auch dann, wenn ich nur ein einziges Volume zur Verfügung habe. So liest es sich ja tatsächlich so, als könne ein ZFS mit Fehlern leben, wenn ich es auf einer einzigen Platte (oder Partition, ihr wisst schon, was ich meine) einsetze.

"Datenverfälschung" habe ich bisher selbst auf meinen USB-Sticks mit FAT-Systemen nicht erlebt und ich transportiere viele kleinere Daten auf solchen Sticks und nutze sie auf unterschiedlichen Systemen, um eben daran zu arbeiten, wie es gerade passt. Natürlich kann ein solcher Stick auch von vorbeifliegenden Aliens beschossen werden und unbrauchbar werden. Die Wahrscheinlichkeit wächst sicher mit der Häufigkeit des Gebrauchs, mit der Beanspruchung der HW.
Und da stimmt es natürlich schon, wenn wir es können, warum sollen wir dann unsere Ansprüche niedriger ansetzen und auf ZFS verzichten?
Vollkommen logisch, auf meinem alten PC läuft nach der letzten Neuinstallation von 10.3 nun auch ZFS auf zwei Platten als Spiegel.
Aber ich bemerke im Betrieb nichts von den vielen Vorteilen, hatte zuvor über neun Jahre UFS auf diesen Platten und dabei auch kein schlechtes Gefühl.

Nochmals vielen Dank für die Antworten.