ZFS hat auf github über 900 offene bureports und steht nicht einmal als Kernel-Patch zur Verfügung. Zwei Dinge die bei mir keinen sehr guten Eindruck hinterlassen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Apr 2016 um 15:49.
ZOL müsste doch mittlerweile auch zu den Linux Dateisystemen zählen. Komisch. Gerade ZFS haben die Oracle Jungs also ausgelassen.
BTRFS schneidet wirklich schlecht ab. Und dann soll das als Standard DS bei einigen Distris eingesetzt werden. Dzz. Selbst Synology setzt es bei einigen NAS Laufwerken schon ein. Ich würde dem meine Daten nicht anvertrauen...
ZOL müsste doch mittlerweile auch zu den Linux Dateisystemen zählen.
Keine Distribution außer Ubuntu unterstützt es offiziell. Und das Oracle lieber die eigene Version von ZFS zusammen mit Solaris verkaufen will, liegt wohl auf der Hand.
Und dann soll das als Standard DS bei einigen Distris eingesetzt werden.
Die einzige Distribution die btrfs standardmäßig einsetzt ist SLES und da auch nur für das root-Dateisystem. Die wichtigen Daten liegen auf einer XFS-Partition. Zwischen den Zeilen gelesen, heißt das für mich, das SuSE btrfs auch noch nicht ganz über den Weg traut.
Nun. Das mit der offiziellen Unterstützung ist doch nur eine Lizenzgeschichte. Trotzdem ist ZOL ein Linuxdateisystem und es ist OSS. Also ein guter Kandidat für so einen Fuzzy-Test.
Zu Btrfs. Die Jungs hier haben mehr Vertrauen als wir. Und dann noch bei Unternehmensdaten:
Ein Fuzzy Test zeigt mögliche Probleme auf, differenziert jedoch prinzipbedingt nicht zwischen real auftretenden und theoretisch vorhandenen.
Wir haben nun schon seit ein paar Jahren mehrere Server mit jeweils 72 512GiB SSDs in einem Pool am Laufen und noch keinerlei mit dem FS selbst gehabt. Im Gegenteil, Recovery nach Hardwareausfall, Snapshotting, Performance pro Geld, Einfachheit der Administration, Stabilität, Erweiterbarkeit, Skalierbarkeit alles um Welten besser als wir es mit sündhaft teuren Hardware Raid Lösungen erlebt hatten. Ich trauere dem keine Sekunde nach und würde jederzeit meine persönlichen und unsere betrieblichen Daten wieder mit Freude hinterherwerfen.
Ich vertraue Btrfs schon seit Jahren meine Daten an und es ist das stabilste und beste FS, welches ich je hatte.
99% aller Datenverluste werden durch menschliche Fehler verursacht und nicht durch das FS. Und dieses Problem wird bei Btrfs durch die Snapshots deutlich entschärft. Mir ist durch Btrfs noch nie eine Datei abhanden gekommen.
Mir schon. Nachdem ich längere Zeit Btrfs genutzt hatte ging plötzlich nichts mehr. Ich hatte am Tag vorher den Rechner ganz normal runtergefahren, also hatte ich auch keine Erklärung. Das System ließ sich weder hochfahren noch reparieren, ich musste es letztlich neu installieren. Seitdem kein Btrfs mehr. Leichtere Probleme gab und gibt es bei jedem Dateisystem immer mal, aber sowas hatte ich noch nie erlebt. Ein Hardwarefehler war es vermutlich auch nicht, denn mit ext4 läuft es seither ohne Probleme seit mindestens einem Jahr.
Ich hab jetzt btrfs seit einigen Jahren laufen, auf einer SSD (auf der ist das System installiert) sowie HDDs (als RAID1), auf denen die (wichtigen) Daten liegen.
Probleme damit hatte ich nicht, außer dass man aufpassen muss wie viel Speicher man frei hat. Nicht, weil das Dateisystem dann irre werden würde (das gab es ja früher mal), sondern, weil die Angaben von df zwar besser als früher aber immer noch nicht ganz präzise sind.
Ansonsten finde ich selbst als Privatanwender die Backupfähigkeiten wesentlich angenehmer als das was ich früher mit rsync o.ä. veranstaltet habe. Insbesondere, dass man so einfach auf die Snapshots zugreifen kann hat mir schon mal den Hintern gerettet.
Über einen HW Ausfall (der HDDs, bei der System SDD wäre mir das recht egal, da mache ich häufiger Backups) mache ich mir wesentlich mehr Gedanken.
Noch als Anmerkung: Ich finde die Tests von Oracle gut. Wenn da durch Fehler in btrfs (oder ext4, xfs etc.) gefunden und behoben werden ist das nur positiv.
Die Ausgabe von df ist nicht falsch, im Gegenteil, sie ist vielleicht "zu korrekt". Wenn du ein btrfs im Raid1 betreibst wird dir die Gesamtkapazität aller Disks angezeigt, legst du nun eine Datei mit 1GiB Größe zB. an, werden heute idR. 2GiB abgezogen (weil sie ja dupliziert wird). Aber das kann/wird sich ändern. Wir sind gerade an einem n-Stripe Patch mit dem man n und nicht nur 1 Kopien erzeugen kann, genauso ist beim btrfs ein Patch im Gange der es erlaubt den Raid Level *pro Datei* festzulegen. Und genau deshalb ist bei btrfs die Angabe des freien Speicher so "komisch". Die tatsächliche freie Kapazität ist bei "Raid1" eben nicht immer zwangsläufig Poolsize / 2. Vielleicht hätte man die "Raidlevel" bei btrfs auch nie "Raid" nennen sollen.
Das was du ansprichst ist das hier, oder? https://btrfs.wiki.kernel.org/index.php/FAQ#How_much_free_space_do_I_have.3F (Und die darauf folgenden Fragen/Antworten.) Also dieses Problem mit RAID1 sehe ich bei df gar nicht. Auch die Gesamtkapazität passt.
Früher aber gab es zwischen brfs fi df und "normalem" df gewisse Unterschiede, die wahrscheinlich mit den Metadaten zu tun hatten (die Gesamtkapazität passte auch damals). Das wurde aber inzwischen gefixt, es passt recht gut. Den genauen Grund kenne ich nicht, da ich mich damit nie näher beschäftigt habe (und hat mich auch nur bedingt interessiert, solange ich rausfinden konnte wie viel Speicher frei war.)
Ich habe schon das Gefühl, dass die Ausgabe von df inzwischen recht gut passt, aber ich bin bei btrfs eben sehr konservativ geworden was die Menge an freiem Speicherplatz angeht. Bei ext3/4 habe ich mir darüber eigentlich nie Gedanken gemacht (außer ich brauchte jetzt explizit eine gewisse Menge an Speicherplatz), wenn es voll war musste man halt schauen, dass sich das ändert. Mit btrfs kontrolliere ich das häufiger als es wahrscheinlich notwendig wäre. Probleme hatte ich aber auch noch nicht, auch wenn es wirklich mal vollgelaufen ist.
Von Btrfs versteher am Mi, 13. April 2016 um 14:23 #
Also ich habe aus Infogruenden seit einigen Wochen die Entwickermailinglist abonniert und lese fleißig. 'Under heavy development' trifft es einfach. Jeden den es interessiert was da täglich an fixes, bug reports und features (z.B. encyption) kommt, sollte da mal etwas stoebern. Und sag ich nur: Wo gehobelt wir fallen Späne! Ergo verstehe ich die Aufregung und das bashing hier nicht. Ja btrfs hat bugs,ist nicht featurecomplete und ist langsam. Aber über kurz oder lang (eher länger) wird es der Standard, ohne Zweifel.
Aber was nicht stört ist die lnformationspolitik. Es wird fast so getan als wäre es kurz vor Produktionsreife, aber imho brauch es noch 5 Jahre zum reifen. Uns die die es pushen wollen sollten da vlt etwas mehr Manpower abstellen, denn die Anzahl der Hauptcontributoren ist ueberschaubar.... Bisher hatte ich gute, sowie erst vor kurzem katastrophale Erfahrungen damit und kurzum Kundendaten landen bei mir zur Zeit wieder auf ZFS, auch wenn mir dort das haendling nicht so ganz gefällt. Privat nutze ich ausschließlich btrfs inkl. RAID.
Schade das Reiser4 auf der Liste fehlt, das Ergebnis hätte mich dann doch interessiert.
Das wäre vermutlich nach 3 Sekunden KO gegangen.
Mal zu sehen wie ZFS abschneidet wäre interessant. Angeblich wird das ja ständig auch mit solchen Fuzzern durchgekaut um Probleme zu erkennen.
ZFS hat auf github über 900 offene bureports und steht nicht einmal als Kernel-Patch zur Verfügung.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Apr 2016 um 15:49.Zwei Dinge die bei mir keinen sehr guten Eindruck hinterlassen.
ZOL müsste doch mittlerweile auch zu den Linux Dateisystemen zählen. Komisch. Gerade ZFS haben die Oracle Jungs also ausgelassen.
BTRFS schneidet wirklich schlecht ab. Und dann soll das als Standard DS bei einigen Distris eingesetzt werden. Dzz. Selbst Synology setzt es bei einigen NAS Laufwerken schon ein. Ich würde dem meine Daten nicht anvertrauen...
Nun. Das mit der offiziellen Unterstützung ist doch nur eine Lizenzgeschichte. Trotzdem ist ZOL ein Linuxdateisystem und es ist OSS. Also ein guter Kandidat für so einen Fuzzy-Test.
Zu Btrfs. Die Jungs hier haben mehr Vertrauen als wir. Und dann noch bei Unternehmensdaten:
https://www.synology.com/de-de/dsm/Btrfs
Ein Fuzzy Test zeigt mögliche Probleme auf, differenziert jedoch prinzipbedingt nicht zwischen real auftretenden und theoretisch vorhandenen.
Wir haben nun schon seit ein paar Jahren mehrere Server mit jeweils 72 512GiB SSDs in einem Pool am Laufen und noch keinerlei mit dem FS selbst gehabt. Im Gegenteil, Recovery nach Hardwareausfall, Snapshotting, Performance pro Geld, Einfachheit der Administration, Stabilität, Erweiterbarkeit, Skalierbarkeit alles um Welten besser als wir es mit sündhaft teuren Hardware Raid Lösungen erlebt hatten. Ich trauere dem keine Sekunde nach und würde jederzeit meine persönlichen und unsere betrieblichen Daten wieder mit Freude hinterherwerfen.
Ich vertraue Btrfs schon seit Jahren meine Daten an und es ist das stabilste und beste FS, welches ich je hatte.
99% aller Datenverluste werden durch menschliche Fehler verursacht und nicht durch das FS. Und dieses Problem wird bei Btrfs durch die Snapshots deutlich entschärft. Mir ist durch Btrfs noch nie eine Datei abhanden gekommen.
Mir schon. Nachdem ich längere Zeit Btrfs genutzt hatte ging plötzlich nichts mehr.
Ich hatte am Tag vorher den Rechner ganz normal runtergefahren, also hatte ich auch keine Erklärung. Das System ließ sich weder hochfahren noch reparieren, ich musste es letztlich neu installieren.
Seitdem kein Btrfs mehr.
Leichtere Probleme gab und gibt es bei jedem Dateisystem immer mal, aber sowas hatte ich noch nie erlebt. Ein Hardwarefehler war es vermutlich auch nicht, denn mit ext4 läuft es seither ohne Probleme seit mindestens einem Jahr.
Probleme damit hatte ich nicht, außer dass man aufpassen muss wie viel Speicher man frei hat.
Nicht, weil das Dateisystem dann irre werden würde (das gab es ja früher mal), sondern, weil die Angaben von df zwar besser als früher aber immer noch nicht ganz präzise sind.
Ansonsten finde ich selbst als Privatanwender die Backupfähigkeiten wesentlich angenehmer als das was ich früher mit rsync o.ä. veranstaltet habe.
Insbesondere, dass man so einfach auf die Snapshots zugreifen kann hat mir schon mal den Hintern gerettet.
Über einen HW Ausfall (der HDDs, bei der System SDD wäre mir das recht egal, da mache ich häufiger Backups) mache ich mir wesentlich mehr Gedanken.
Noch als Anmerkung:
Ich finde die Tests von Oracle gut. Wenn da durch Fehler in btrfs (oder ext4, xfs etc.) gefunden und behoben werden ist das nur positiv.
Die Ausgabe von df ist nicht falsch, im Gegenteil, sie ist vielleicht "zu korrekt". Wenn du ein btrfs im Raid1 betreibst wird dir die Gesamtkapazität aller Disks angezeigt, legst du nun eine Datei mit 1GiB Größe zB. an, werden heute idR. 2GiB abgezogen (weil sie ja dupliziert wird). Aber das kann/wird sich ändern. Wir sind gerade an einem n-Stripe Patch mit dem man n und nicht nur 1 Kopien erzeugen kann, genauso ist beim btrfs ein Patch im Gange der es erlaubt den Raid Level *pro Datei* festzulegen. Und genau deshalb ist bei btrfs die Angabe des freien Speicher so "komisch". Die tatsächliche freie Kapazität ist bei "Raid1" eben nicht immer zwangsläufig Poolsize / 2. Vielleicht hätte man die "Raidlevel" bei btrfs auch nie "Raid" nennen sollen.
Das was du ansprichst ist das hier, oder?
https://btrfs.wiki.kernel.org/index.php/FAQ#How_much_free_space_do_I_have.3F
(Und die darauf folgenden Fragen/Antworten.)
Also dieses Problem mit RAID1 sehe ich bei df gar nicht. Auch die Gesamtkapazität passt.
Früher aber gab es zwischen brfs fi df und "normalem" df gewisse Unterschiede, die wahrscheinlich mit den Metadaten zu tun hatten (die Gesamtkapazität passte auch damals). Das wurde aber inzwischen gefixt, es passt recht gut. Den genauen Grund kenne ich nicht, da ich mich damit nie näher beschäftigt habe (und hat mich auch nur bedingt interessiert, solange ich rausfinden konnte wie viel Speicher frei war.)
Ich habe schon das Gefühl, dass die Ausgabe von df inzwischen recht gut passt, aber ich bin bei btrfs eben sehr konservativ geworden was die Menge an freiem Speicherplatz angeht.
Bei ext3/4 habe ich mir darüber eigentlich nie Gedanken gemacht (außer ich brauchte jetzt explizit eine gewisse Menge an Speicherplatz), wenn es voll war musste man halt schauen, dass sich das ändert.
Mit btrfs kontrolliere ich das häufiger als es wahrscheinlich notwendig wäre. Probleme hatte ich aber auch noch nicht, auch wenn es wirklich mal vollgelaufen ist.
Also ich habe aus Infogruenden seit einigen Wochen die Entwickermailinglist abonniert und lese fleißig.
'Under heavy development' trifft es einfach. Jeden den es interessiert was da täglich an fixes, bug reports und features (z.B. encyption) kommt, sollte da mal etwas stoebern.
Und sag ich nur: Wo gehobelt wir fallen Späne!
Ergo verstehe ich die Aufregung und das bashing hier nicht.
Ja btrfs hat bugs,ist nicht featurecomplete und ist langsam. Aber über kurz oder lang (eher länger) wird es der Standard, ohne Zweifel.
Aber was nicht stört ist die lnformationspolitik. Es wird fast so getan als wäre es kurz vor Produktionsreife, aber imho brauch es noch 5 Jahre zum reifen. Uns die die es pushen wollen sollten da vlt etwas mehr Manpower abstellen, denn die Anzahl der Hauptcontributoren ist ueberschaubar....
Bisher hatte ich gute, sowie erst vor kurzem katastrophale Erfahrungen damit und kurzum Kundendaten landen bei mir zur Zeit wieder auf ZFS, auch wenn mir dort das haendling nicht so ganz gefällt. Privat nutze ich ausschließlich btrfs inkl. RAID.
Gut ding will eben Weile haben.