encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17448
|
Cruiz schrieb: Allerdings weiß ich natürlich nicht, ob es in der Implementierung zwischen SUSE und Arch Unterschiede gibt.
Ich glaube (nicht wissen!) das nur noch die Enterprise Distrubtionen groß am Kernel rumpatchen, also SLES, RHEL und CentOS. Bei den "normalen" Distributionen werden keine so großen Dinge mehr gepatcht, das war früher mal anders. mfg Stefan Betz
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
Tids schrieb: ungelogen jedes einzelne mal wenn der Strom unvorhersehbar getrennt wurde oder ein Hardreset bei einem Freeze durchgeführt werden musste. Danach kann die BTRFS Partition schlicht nicht mehr eingebunden werden. Leider habe ich die Fehlermeldungen nicht mehr.
Btrfs sollte eigentlich immer einen konsistenten Zustand haben, egal wo es gerade unterbrochen wurde. TheDarkRose schrieb: Lässt sich aber für z.B. das /var/lib/mysql Verzeichnis per chattr +C deaktivieren.
Notiz am Rande: Deaktiviertes CoW gilt dann aber nur für neue angelegte Dateien innerhalb des Ordners. Ebenso kann man einer Datei nicht nach dem Erstellen die CoW-Funkionalität nehmen (bzw: sollte man nicht), das muss geschehen bevor man Daten in die Datei schreibt. Auszug aus der manpage:
"For btrfs, the 'C' flag should be set on new or empty files. If it is set on a file which already has data blocks, it is undefined when the blocks assigned to the file will be fully stable. If the 'C' flag is set on a directory, it will have no effect on the directory, but new files created in that directory will have the No_COW attribute."
Um auf die ursprüngliche Frage zurückzukommen:
„Btrfs - aktueller Stand?“
Abgesehen von RAID5/6 sehe ich das Dateisystem als stabil an, CoW muss für manche Sachen deaktiviert werden, aber ansonsten ganz nett (auch, wenn man nicht alle Funktionen nutzt).
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Developer92 schrieb: CoW muss für manche Sachen deaktiviert werden
Für welche? (außer den genannten MySQL und PostgreSQL)
|
glasenisback
Anmeldungsdatum: 20. November 2011
Beiträge: 1603
Wohnort: Fernwald (Gießen)
|
Cruiz schrieb: OpenSUSE und SUSE Linux Enterprise setzten das bereits seit geraumer Zeit standardmäßig ein.
Du musst in diesem Fall zwischen den Zeilen lesen: Btrfs wird nur für das root-Dateisystem eingesetzt, für die Benutzerverzeichnisse wird ein anderes Dateisystem (XFS oder Ext4) verwendet. Das sagt eigentlich schon alles.
|
Cruiz
Anmeldungsdatum: 6. März 2014
Beiträge: 5557
Wohnort: Freiburg i. Brsg.
|
glasenisback schrieb: Cruiz schrieb: OpenSUSE und SUSE Linux Enterprise setzten das bereits seit geraumer Zeit standardmäßig ein.
Du musst in diesem Fall zwischen den Zeilen lesen: Btrfs wird nur für das root-Dateisystem eingesetzt, für die Benutzerverzeichnisse wird ein anderes Dateisystem (XFS oder Ext4) verwendet. Das sagt eigentlich schon alles.
Aber nur, wenn man eine separate Home-Partition verwendet. Je nach Festplattengröße schlägt der SUSE-Installer das nicht vor.
|
k1l
Anmeldungsdatum: 22. September 2006
Beiträge: 1253
Wohnort: Köln
|
Cruiz schrieb: Ubuntu scheint aber auf ZFS zu setzen (siehe erste Schritte in 16.04), von daher glaube ich nicht, dass btrfs in naher Zukunft standardmäßig von Ubuntu eingesetzt werden wird.
Ich hatte das bisher so interpretiert, als wenn man ZFS extra für die Server/Container Setups aufgenommen hat. Der Installer bietet weiterhin (noch) nicht an, das / als ZFS zu formatieren. Ich denke ext4 wird im Userbereich noch eine ganze weile Standard bleiben bei ubuntu. Beim BtrFS sind wir jetzt auch schon seit Jahren kurz vor dem gefühlten Durchbruch, das fällt dann sicher mit dem "Jahr des Linux-Desktops" zusammen 😀 Normalerweise macht eine große Distri den ersten Schritt, dann kommen da eine Menge Probleme bei den Normalos zu tage, diese werden dann behoben, und dann ziehen andere Distris nach. Aber ich weiß nicht so richtig warum das hier nicht in Gang gekommen ist nachdem (open)Suse das ja seit 13.2 (2014) ausliefert. Entweder liegt es an den technischen Problemen (fsck anyone?) oder eben daran, dass der Herr Otto Normal den ganzen Spökes gar nicht braucht (oder will).
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
encbladexp schrieb:
Unabhängig vom Dateisystem sollte man aber Backups haben, ein Datenverlust kann immer möglich sein, nicht nur weil dein Dateisystem gerade etwas zu viel getrunken hat.
Ich kann das nur unterstützen: ich hatte die Tage sogar ein Problem im ext4-Dateisystem, das nicht durch Stromausfall oder Plattenproblem o.ä. ausgelöst wurde sondern offensichtlich durch einen Bug in der Dateisystemimplementierung. Vorsicht, Mutter und Porzellankiste - Ihr kennt das ja.
|
Cruiz
Anmeldungsdatum: 6. März 2014
Beiträge: 5557
Wohnort: Freiburg i. Brsg.
|
k1l schrieb: Ich hatte das bisher so interpretiert, als wenn man ZFS extra für die Server/Container Setups aufgenommen hat. Der Installer bietet weiterhin (noch) nicht an, das / als ZFS zu formatieren. Ich denke ext4 wird im Userbereich noch eine ganze weile Standard bleiben bei ubuntu.
Das denke ich auch und wollte hier natürlich auch nichts gegenteiliges behaupten. Ich wollte lediglich andeuten, dass, sofern überhaupt irgendwann mal ein Wechsel von ext4 erfolgen sollte, Btrfs nicht der wahrscheinlichste Kandidat ist, da Canonical bis dahin viel Erfahrung mit ZFS haben wird.
Beim BtrFS sind wir jetzt auch schon seit Jahren kurz vor dem gefühlten Durchbruch, das fällt dann sicher mit dem "Jahr des Linux-Desktops" zusammen 😀 Normalerweise macht eine große Distri den ersten Schritt, dann kommen da eine Menge Probleme bei den Normalos zu tage, diese werden dann behoben, und dann ziehen andere Distris nach. Aber ich weiß nicht so richtig warum das hier nicht in Gang gekommen ist nachdem (open)Suse das ja seit 13.2 (2014) ausliefert. Entweder liegt es an den technischen Problemen (fsck anyone?) oder eben daran, dass der Herr Otto Normal den ganzen Spökes gar nicht braucht (oder will).
Es gibt da schon ein paar ganz nette Funktion - Stichwort Snapshots - die auch für Otto-Normal-Nutzer interessant wären. Im diese sinnvoll zu nutzen bräuchte man aber eine grafische Oberfläche, die sich sinnvoll in den Desktop integriert. Denn theoretisch lässt sich damit ein Dateiverlauf wie bei Apple oder Microsoft realisieren. Allerdings würden die Neokonservativen der Linux-Welt dann wieder Verrat brüllen, weil man dann ja ein Dateisystem bevorzugen würde und jeder Fortschritt des Teufels ist.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17448
|
So lange ZFS nicht mit dem vanilla Kernel ausgeliefert wird, wird es auch kein Standarddateisystem werden. Ubuntu probiert aktuell halt aus was so möglich ist, nicht mehr, nicht weniger. Der Rest der Linux Welt bietet viele Features nur exklusiv für btrfs an, was zumindest schon mal im Kernel ist. Was die Entwicklung und den Durchbruch von btrfs angeht: Es wird mit jedem Kernel Release besser, Problem war einfach das die Ankündigungen von "Wir wechseln mit dem nächsten Release" viel zu früh waren, noch lange bevor btrfs wirklich so weit war. Damals hätte ich nichtmal mein /-Dateisystem damit laufen lassen, heute ist btrfs für vieles mein Standarddateisystem. Auch RAID & Co verzichte ich gegenwärtig dabei aber noch, da nehme ich die alten bekannten 😉 mfg Stefan Betz
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
V_for_Vortex schrieb: Developer92 schrieb: CoW muss für manche Sachen deaktiviert werden
Für welche? (außer den genannten MySQL und PostgreSQL)
Spontan würde ich sagen:
Datenbanken Torrents Virtuelle Maschinen
CoW ist immer da ein Performance-Fresser, wo innerhalb einer bestehenden Datei immer wieder Bereiche geändert werden. Und gerade bei den genannten Dingen ist das innerhalb kurzer Zeit sehr oft der Fall, weshalb die Performance mit Copy-on-Write gegen Null geht. Muss man wissen, wenn man solche Dateisysteme nutzt, für den normalen, durchschnittlichen Nutzer im alltäglichen Gebrauch aber relativ unwichtig. (Ich bin ja gerade noch am Überlegen, ob man CoW auch nicht generell für Verzeichnise wie ~/.cache deaktivieren sollte)
k1l schrieb: Beim BtrFS sind wir jetzt auch schon seit Jahren kurz vor dem gefühlten Durchbruch, das fällt dann sicher mit dem "Jahr des Linux-Desktops" zusammen 😀
Das könnte daran liegen, weil die Leute oft nicht einschätzen können, wie es ist ein Dateisystem zu entwickeln (nicht, dass ich da jetzt Erfahrung hätte, aber ich gehe das Thema gerne gedanklich an…): Btrfs ist tatsächlich gerade mal ein Jahr jünger als ext4, allerdings steckt in ext4 das Wissen der Vorgänger (ext3, ext2, ext (?)), wohingegen btrfs komplett neue Features bietet die man bisher nur in wenigen Dateisystemen gesehen hat. Ext4 ist stabil, ausgereift, beruht auf Code der schon wesentlich älter ist als das Dateisystem selbst. Btrfs versucht hingegen so viele Funktionen (Kompression, Deduplizierung, RAID, Snapshots, Subvolumes) zu vereinen, dass hier zwangsweise Bugs gefunden werden, mit denen man vorher nicht gerechnet hat. Früher™ hatte man zwei bis drei Layer (bspw. RAID → LVM → Dateisysteme), welche nun mit einem einzigen Dateisystem erschlagen werden. Die Komplexität steigt dadurch enorm und führt auch zu interessanten neuen Herausforderungen (etwa: Wie berechne ich bei einem btrfs-Dateisystem den restlichen verfügbaren Speicher, wenn ich mehrere RAID-Level gemischt habe, Subvolumes und Snapshots nutze?). Dauert natürlich, bis das alles mal stabil ist. Und für die Entwicklungszeit finde ich persönlich das Ergebnis ganz ordentlich, auch wenn es noch nicht perfekt läuft (RAID5/6 🙄 ). Zum dem Thema habe ich zufälligerweise auch einen Artikel, der versucht das grob darzustellen: Dateisysteme - Generationen
Normalerweise macht eine große Distri den ersten Schritt, dann kommen da eine Menge Probleme bei den Normalos zu tage, diese werden dann behoben, und dann ziehen andere Distris nach.
Ich hätte jetzt gesagt würde jetzt behaupten, dass "Normalos" neue Dateisysteme erst dann bekommen, wenn diese schon ziemlich ausgereift sind. Ein "normaler" Nutzer bringt für den Entwickler ja relativ wenig. Wenn ich wissen will, wie gut mein Dateisystem ist, muss ich das in großem Umfang testen, sprich: In Umgebungen, wo ich es an die Grenzen bringe. Und das machen Privatleute doch relativ selten, oder nicht? (Weil es mir gerade einfällt: Syncthing ist da auch so ein Fall. Die Software nutzen Leute in der Regel eher dafür, um ein paar Gigabyte Daten über mehrere Geräte hinweg synchron zu halten. Aber dann gibt es eben so Ausreißer, die versuchen damit mehr als ein Terabyte Daten synchron zu halten. Ich finde das immer ganz interessant, weil man da erst sieht, wo die Software noch Probleme bereitet. Für den normalen Betrieb funktioniert das Ding ja ganz zuverlässig, aber an die Grenzen stößt man dann eben erst mit entsprechenden Datenmengen. Und bei Dateisystemen dürfte es nicht viel anders sein, wenn ich wissen will was das Ding kann muss ich die Features in großem Stil testen, und das machen dann wohl eher Firmen auf Testsystemen als der durchschnittliche Nutzer)
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17448
|
Developer92 schrieb:
Sind in der Regel Sparse Files, also gegenüber CoW kein Problem. Es wird eine X GB große Datei reserviert, und erst mit Daten beim Download beschrieben.
Btrfs ist tatsächlich gerade mal ein Jahr jünger als ext4, allerdings steckt in ext4 das Wissen der Vorgänger (ext3, ext2, ext (?)), wohingegen btrfs komplett neue Features bietet die man bisher nur in wenigen Dateisystemen gesehen hat.
Man sagt ja auch immer: Ein Dateisystem kann man erst nach ~10 Jahren Erfahrung/Entwicklung in der Praxis einsetzen. mfg Stefan Betz
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
encbladexp schrieb: Sind in der Regel Sparse Files, also gegenüber CoW kein Problem. Es wird eine X GB große Datei reserviert, und erst mit Daten beim Download beschrieben.
Hm, stimmt. Daran hatte ich nicht gedacht.
Man sagt ja auch immer: Ein Dateisystem kann man erst nach ~10 Jahren Erfahrung/Entwicklung in der Praxis einsetzen.
Also 2019 dann das Jahr von btrfs (und des Linux-Desktops? 😉 )
Edit: Die Doku zu btrfs sagt bezüglich Fragmentierung durch Copy-on-Write:
On desktops this primarily affects application databases (including Firefox and Chromium profiles, GNOME Zeitgeist, Ubuntu Desktop Couch, Banshee, and Evolution's datastore.)
Macht also Sinn hierfür CoW zu deaktivieren.
|
HasserDesErfolges
Anmeldungsdatum: 19. August 2010
Beiträge: 141
|
Cruiz schrieb: Allerdings würden die Neokonservativen der Linux-Welt dann wieder Verrat brüllen, weil man dann ja ein Dateisystem bevorzugen würde und jeder Fortschritt des Teufels ist.
😊 👍 😈 🤣 😬 Du bist der größte , Cruiz !!
|
jedie
Anmeldungsdatum: 14. Oktober 2005
Beiträge: 516
|
Ich hatte mal ein Ubuntu installiert und für root btrfs genutzt. Irgendwie lief das nicht wirklich rund. Wobei ich nicht sagen kann, was genau das Problem war... Dennoch nutzte ich btrfs für externe Platten gern. Wegen Kompression und deduplizierung... Aber deduplizierung funktioniert leider nur offline (ich nutzte https://github.com/g2p/bedup dazu) Doch ich Frage mich eigentlich, wie kann ich sehen, was Kompression und deduplizierung wirklich bringt. bedup show spuckt dann sowas aus: As of generation 11988, tracking 63626 inodes of size at least 8388608
Ja, und was soll mir das nun sagen? Wieviel MB hab ich denn nun eingespart?!? btrfs filesystem df zeigt das:
| Data, single: total=1.76TiB, used=1.76TiB
System, DUP: total=8.00MiB, used=240.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=4.00GiB, used=3.25GiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=512.00MiB, used=0.00B
|
Zeit mit IMHO auch nicht an, was ich gespart hab, oder?!? und das neuere btrfs filesystem usage macht es auch nicht wirklich besser. Im Wiki finde ich dazu auch nichts. Hab ich was übersehen?
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
jedie schrieb: Doch ich Frage mich eigentlich, wie kann ich sehen, was Kompression und deduplizierung wirklich bringt.
Soweit ich weiß ist das im Moment auch nicht direkt möglich.
bedup show spuckt dann sowas aus: As of generation 11988, tracking 63626 inodes of size at least 8388608
Ja, und was soll mir das nun sagen? Wieviel MB hab ich denn nun eingespart?!?
Das Tool duperemove zeigt das an - aber ganz ehrlich lohnt sich das für den Heimgebrauch nicht wirklich. Wir reden hier von Einsparungen in Bereichen von einige Kilobyte bis wenigen Megabyte, sofern du nicht gerade dutzende Datenbestände dupliziert bei dir herumliegen hast (wovon ich jetzt einmal ausgehe). Kompression bringt da insgesamt wesentlich mehr (und läuft auch sauber transparent im Hintergrund). Die Kompressionsrate lässt sich aber auch nicht direkt ermitteln, du kannst lediglich die Größe deines Datenbestands feststellen, gucken wie groß die Festplatte ist, wie viel noch frei ist, wie viel vorraussichtlich noch an Daten geschrieben werden können und damit dann die Kompression mehr oder weniger genau ausrechnen. Aufgrund der Komplexität von btrfs ist das aber auch kein einfaches Unterfangen, schließlich werden hier Subvolumes, RAID-Level und Kompression von einem einzigen Tool bereitgestellt. Auch der freie Speicherplatz, den btrfs-Dateisysteme anzeigen, ist das, was du Minimum noch an Daten schreiben kannst. Auch hier gibt es die Problematik mit RAID-Level, Subvolumes und Kompressionsverfahren. Alternativ kann man auch einen Mittelwert nehmen und bspw. von 5-6% Einsparung bei Einsatz eines Kompressionsverfahrens pauschal ausgehen. Bringt aber auch nicht wirklich viel, und ganz ehrlich macht es auch keinen Unterschied ob das jetzt 4,5% oder 5% sind. (Auf einer anderen Ebene mal gefragt: Was bringt dir das, wenn du die Kompressionsrate kennst? Die eingesetzten Verfahren sind auf Geschwindigkeit ausgelegt, nicht auf möglichst gute Kompressionsraten. Und es macht – meiner Einschätzung nach – auch wenig Sinn für Anwender das überhaupt herauszufinden. Wenn mir der Speicherplatz ausgeht kann ich mit Kompression noch ein bisschen was herausquetschen, aber zwangsweise wrid man irgendwann dann sowieso eine größere Festplatte benötigen)
|