Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: Red Hat wendet sich von Btrfs ab

30 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
2
Von klaus818 am Mi, 2. August 2017 um 12:12 #

Man kann an der Kiste rumbasteln, wie man mag. Sollte etwas schief gehen, bumms hat man die alte Version wieder da. Probleme, die auf Btrfs zurückzuführen sind, hatte ich noch keine.

Ganz im Gegenteil, ich denke mal, es ist schon wesentlich öfters vorgekommen, dass man mal aus Versehen eine Datei gelöscht oder kaputteditiert hat.

  • 3
    Von pataa am Mi, 2. August 2017 um 12:27 #

    Unter OpenSuSE nutze ich kein BtrFS, weil es mir schon paar mal hoch ging und ich eben nichts zurück holen können. Außerdem ist BtrFS mMn. langsam. Wechsel auf Ext4 bringt mehr Stabilität und Speed.

    • 1
      Von blubb am Mi, 2. August 2017 um 14:37 #

      Tja, so kann es gehen. Ich hatte mit Ext4 schon mehrfach Datenverlust und korrumpierte Dateien (hauptsächlich auf externen Datenträgern mit Sicherungen, war in dem Fall aber kein HW Problem).
      Mit btrfs hatte ich bislang überhaupt keine Probleme.

      1
      Von Viking42 am Mi, 2. August 2017 um 16:28 #

      Bei mir läuft BTRFS ganz stabil, und bisher hatte ich noch keinen Datenverlust. Selbst wenn, habe ich davon Backups. Mit ext3/ext4 durfte ich hingegen schon des öfteren Backups einspielen dürfen. Schneller ja, Stabil naja.

      1
      Von klaus818 am Mi, 2. August 2017 um 19:54 #

      Mehr Stabilität garantiert nicht. Mehr Speed schon. Klar, habe gestern mal rumgespielt, Kiste zerschossen. Alternativen: Neuinstallation oder Snapshot. Neuinstallation (Gentoo) 2 Tage, Snapshot 2 Minuten.

      Wenn ich mal schnell was testen will, Snapshot dauert 1 Sekunde. Geht es schief, System zurückspielen.

      Für diese Features nehme ich die Performance in Kauf. Sollte xfs vergleichbare Features bieten, dann sind die Spiele eröffnet. Aber ankündigen kann man viel.

      • 0
        Von schmidicom am Fr, 4. August 2017 um 08:28 #

        Nach dem hinzufügen der reflink-Funktionalität ist zumindest eine Art von Datei basiertem Snapshoting möglich und somit dürfte der Weg hin zu einer snapshot-Funktion wie sie btrfs hat wohl auch nicht mehr allzu weit sein.
        Ich denke also schon das dies noch kommen wird.

        • 1
          Von klaus818 am Fr, 4. August 2017 um 10:26 #

          Ich sagte doch, dann sind die Spiele eröffnet. Abwarten. Wie das dann mit der Performance und den Bugs aussehen wird, das steht auf einem anderen Blatt. Schaltest du bei btrfs COW ab, dann rennt es ja auch wie Sau. Und das Gleiche wird bei xfs passieren, es wird einen Performanceeinbruch geben.

          Des weiteren lassen sich einige Probleme von btrfs umschiffen, wenn man COW für einige Ordner gezielt abschaltet. VMs sind da ja so eine Sache. Bei einer kleinen Änderung werden gleich ein paar GB geschrieben... Oder bei mir /var/log. Warum sollte man die jedes mal komplett neu schreiben, wenn sie kontinuierlich wachsen?

      1
      Von blubb am Mi, 2. August 2017 um 20:07 #

      Außerdem ist BtrFS mMn. langsam.
      Wollte noch hinzufügen, dass ich dir in dem Punkt zustimme.

      Besonders wenn das Dateisystem gut gefüllt ist wird btrfs wirklich recht langsam. Da kann es dann auch mal ein paar Sekunden dauern eine Datei zu löschen.

      Mir persönlich ist das aber recht egal. Performance ist an der Stelle (für mich) zweitrangig.
      An anderer Stelle kann das natürlich signifikant sein.

      1
      Von Antiquities am Do, 3. August 2017 um 09:31 #

      das meinst du doch nicht ernsthaft.

    1
    Von autarch am Mi, 2. August 2017 um 13:05 #

    Nun wie am Ende des Artikels steht, XFS wird bald auch COW-Snapshots unterstützen und es ist ansonsten ein deutlich performateres, stabileres und skalierbareres Dateisystem.
    Snapper auf Suse ist schon echt nicht schlecht, ich habe damit mal eine vermurkste Nvidiatreiberinstallation einfach zurücksetzen können.
    Aber Btrfs hat ja nicht nur COW hinzugefügt, was unter gewissen Umständen sinn macht, sondern auch anderen Unsinn wie Subvolumes und RAID. Das gehört nicht ins FS, dafür gibt es schon md und LVM auf der einen und Ordner auf der anderen Seite (Subvolumes in Btrfs haben für mich keinen erkennbaren Unterschied zu Ordnern, außer dass Btrfs zu schlecht gemacht ist um gewisse Eigenschaften auf Ordnerbasis setzen zu können, man sie aber trotzdem nicht für das ganze FS setzen will).

    Dieser Beitrag wurde 2 mal editiert. Zuletzt am 02. Aug 2017 um 13:24.
    • 1
      Von blubb am Mi, 2. August 2017 um 14:42 #

      Aber Btrfs hat ja nicht nur COW hinzugefügt, was unter gewissen Umständen sinn macht, sondern auch anderen Unsinn wie Subvolumes und RAID. Das gehört nicht ins FS, dafür gibt es schon md und LVM auf der einen
      Nun, das ist deine Sichtweise. Ich nutze genau aus dem Grund btrfs.
      Die Implementierung im FS hat hier große Vorteile, wenn es um die Synchronisierung und Verifizierung der Daten geht.
      Und Subvolumes haben den Vorteil, dass man hier sehr einfach Snapshots erstellen kann.
      Finde ich persönlich für Backups sehr praktisch.
      Ich möchte das nicht mehr missen.

      md habe ich früher genutzt, bin aber davon abgekommen seit ich btrfs im Einsatz habe.
      md+LVM+Ext4 fand ich persönlich immer eher unflexibel.
      Für den Datenspeicher meines Desktop-PCs hatte ich letztes Jahr beide Festplatten (RAID1) gegen neuere ausgetauscht.
      In btrfs war das benuzterseitig extrem einfach zu handeln. 3-4 Befehle (inkl. aufspannen der Volumes auf die neue Größe).
      Mit md+LVM+Ext4 wäre das auch möglich gewesen, aber wesentlich komplexer umzusetzen.

      und Ordner auf der anderen Seite (Subvolumes in Btrfs haben für mich keinen erkennbaren Unterschied zu Ordnern, außer dass Btrfs zu schlecht gemacht ist um gewisse Eigenschaften auf Ordnerbasis setzen zu können, man sie aber trotzdem nicht für das ganze FS setzen will).
      Dafür sind die Subvolumes auch nicht da.

      2
      Von klaus818 am Mi, 2. August 2017 um 20:04 #

      Nun ja, warum Subvolumes und Raid ins FS gehören, darüber wurde hinlänglich berichtet. Raid im FS ist deutlich überlegen. Aber darum geht es mir nicht, ich nutze kein Raid.

      Hm, du hast einfach nichts verstanden. Ohne Subvolumes kein Snapshots. Ein Snapshot ist ein Subvolume, welches schon mit Daten vorbelegt ist.

      Ich denke einfach mal, du hast Btrfs nie genutzt und es nie verstanden. Das, was ich brauche, das funktioniert wunderbar. Raid ist noch nicht fertig, aber die beste Variante, wenn es funktioniert.

      2
      Von KDE Fan am Fr, 4. August 2017 um 00:35 #

      sondern auch anderen Unsinn wie Subvolumes und RAID. Das gehört nicht ins FS, dafür gibt es schon md und LVM auf der einen und Ordner auf der anderen Seite
      Genau das Gegenteil von dem was Du schreibst. Es ist gerade von Vorteil, wenn der logical volume manager Bestandteil des FS ist. Übrigens auch eins der Designkriterien, worauf ZFS basiert. Wie klaus818 schon geschrieben hat. Du hast den Sinn nicht verstanden.

1
Von Ruediger am Mi, 2. August 2017 um 12:34 #

ReFS von Microsoft ist nicht einmal bootfähig und auch nicht auf externen Medien nutzbar. Also es gibt schlimmeres.

  • 1
    Von Popel am Mi, 2. August 2017 um 14:07 #

    ReFS wurde ja auchnicht für Heimanwender oder externen Speicher entwickelt, sondern für viele TB große Storagesysteme welche die Features von NTFS nicht benötigen und/oder nicht haben wollen. Zudem ist es auf Storagesystemen, vergleichen mit NTFS, schneller, was ein Vorteil ist.

    • 1
      Von Scàth am Mi, 2. August 2017 um 14:15 #

      Der derzeitige (seit Win Server 2016) Haupteinsatz ist auch auf VMs, VHDX und S2D - eben wie du sagst auf entsprechend großen Storage-Systemen. Dort spielt ReFS aber seine Stärken auch voll aus, dazu braucht es aber auch nicht bootbar sein.
      Irgendwann wird ReFS NTFS vermutlich vollständig ablösen, aber das wird noch einige Zeit dauern. ReFS hat hervorragende Eigenschaften, das muss man neidlos anerkennen. Da gibt es nichts worüber man sich lustig machen sollte, oder könnte (außer man hat keine Ahnung von der Materie).

      • 1
        Von Ruediger am Mi, 2. August 2017 um 23:03 #

        Laut Wikipedia kann ReFS nicht einmal Hardlinks. Aber ich wette dass die Locky- und Virenunterstützung perfekt ist.

        • 1
          Von Scàth am Do, 3. August 2017 um 21:57 #

          Wenn du dein "Wissen" nicht gerade von der Wikipedia holen würdest, wüsstest du das hardlinks von Microsoft in ReFS gar nicht erst unterstützt werden soll.

          Aber danke für deinen üblichen "Microsoft ist scheiße Beitrag". Sinnvolles oder gar konstruktives wird man von dir wohl nicht bekommen.

0
Von schmidicom am Mi, 2. August 2017 um 14:25 #

Davon werden sich auch noch weitere abwenden, zumindest dann wenn die Entwickler die gemeldeten Fehler nicht bald mal etwas ernster nehmen.

Nur so ein Beispiel:
Wird bei Verwendung von btrfs das System ohne ein initrd gestartet, was durchaus vorkommen kann, scheint es während dem Start kein brauchbares "/dev/root" zu geben was zumindest schon einmal dem "systemd-gpt-auto-generator" nicht gefällt.
https://bugs.freedesktop.org/show_bug.cgi?id=84689
https://bugzilla.kernel.org/show_bug.cgi?id=89721
Seit Dezember 2014 bekannt und nichts passiert...

  • 1
    Von mnbvcxy am Mi, 2. August 2017 um 16:34 #

    Wer soll sich denn da noch abwenden? Laut Nachricht setzen ja nur Opensuse und SLES Btrfs als Standarddateissystem ein.

    Ein netter Wettbewerb, der sich da entwickeln wird. Wir werden sehen, was sich langfristig am Servermarkt durchsetzt, das Red Hat-unterstützte, "alte" Xfs, das von der Community und Google favorisierte Ext4 oder das von Suse gepushte Btrfs.

    Ich denke, dass Red Hat dieses Mal auf dem Holzweg ist und zwar kräftig. Sie lassen sich zu sehr von der Tatsache ablenken, dass Suse auf Btrfs setzt. Bugs waren noch nie ein Problem für Red Hat, da man diese normalerweise selbst angeht. Aber in punkto Btrfs würde man ja Suse und damit einem direketen Konkurrenten mithelfen, der in punkto Btrfs-Know-How schon Lichtjahre weiter ist, also macht man IMO deshalb eine 180 Grad-Kehrtwende.

    Das Ganze ähnelt dem früheren Quasi-Reiserfs 3-Boykott außerhalb des SuSE-Bereiches.

1
Von Meinereinerdernichtexistiert am Mi, 2. August 2017 um 19:10 #

Bei den aktuellen Mediengrößen ist die Warscheinlichkeit, daß es in den Daten einen Bitdreher gibt, nicht mehr vernachlässigbar. Bei den meisten Filesystemen bleibt ein solcher Fehler unbemerkt und unterwandert mit der Zeit sogar das Backup. Wenn man es dann merkt, ist keine korrekte Version mehr verfügbar.

Das einzigste Filesystem (im Standardkernel), das Datenchecksummen besitzt, ist Btrfs. Somit gibt es für mich keinerlei Alternative zu Btrfs.

Klar, ZFS hat auch Datenprüfsummen und macht es somit zu einer Alternative. Aber es erfordert doch weitaus mehr Aufwand, es einzusetzen.

Hinzu kommt, daß mir ext3 schon mehrfach ganze Partitionen geschrottet hat. Außerdem war es (im Gegensatz zu ext4) schnarchlangsam. Das XFS aufgebohrt wird, begrüße ich, nur leider hat auch XFS keine Datenprüfsummen und ist somit keine Alternative.

  • 1
    Von KarlK am Mi, 2. August 2017 um 21:09 #

    Das war auch die Überlegung in meinem Labor, wir speichern >120tb an genetischen Daten jetzt in BTRFS, seit mehr als einem Jahr ohne Probleme. Checksummen, Snapshots und vor allem die Möglichkeit das Dateisystem nachträglich zu vergrößern waren die ausschlaggebenden Faktoren.

    1
    Von blablabla233 am Do, 3. August 2017 um 14:56 #

    Stimmt nicht NILFS2 unterstützt auch Meta und Daten-Prüfsummen und ist extrem stabil.

    1
    Von blablabla233 am Do, 3. August 2017 um 14:57 #

    XFS wird auch bald Prüfsummen auf alles haben, halt im moment erst auf Metadaten...aber eben NILFS2 :-)

    1
    Von mnbvcxy am Do, 3. August 2017 um 21:52 #

    Wie man in Debian Stretch sieht, kommt auch hier Ext4 mit dem Feature data checksums.

1
Von Knorke am Do, 3. August 2017 um 08:47 #

Ich wechsle gerade auf btrfs, weil Bugs in overlayFS (auch in Version 2) die Verwendung von Containern stark einschränken. Verrückte Welt.

1
Von KDE Fan am Fr, 4. August 2017 um 01:00 #

Bei Golem läuft eine ähnliche Diskussion. Ein User postete unter dem Titel "broken by design" diesen Link zu Btrfs:

www.slicewise.net/debian/balancierung-eines-vollen-btrfs-dateisystems/

Btrfs hatte wohl mal Probleme mit dem Rebalancing des B-Baums. Ist das wohl noch immer der Fall? Einige User hier berichteten von Datenverlust. Evtl. hätte der eine oder andere mit tiefergehender Kenntnis von Btrfs ja Daten retten können.
Ich wusste bisher nicht, dass man manuell ein Rebalancing durchführen kann.

Auch interessant ist dies:

Es gab mal von Edward Shishkin die Behauptung, dass es broken-by-design wäre. Das wurde aber widerlegt, bzw Edward konnte seine Behauptung nicht beweisen:

https://lkml.org/lkml/2010/6/3/313

2
Von wurzel am Di, 8. August 2017 um 21:28 #

war Linux für mich ein Minenfeld .. Irgendein Update oder ein Manipulation meinerseits zerlegten das System.
Vielfach konnte man es wieder hinbasteln aber manchmal eben nicht. -- Neuinstallation
Da war etwas Fanatismus gefragt ..

Mit btrfs kann ich jetzt sogar sorglos im Bekanntenkreis Linux incl. root-Zugang ausrollen. Nach dem allfälligen Blödsin: Ein Rollback und alles ist wieder wie es vorher war.
Linux hat seine Schrecken verloren.

Für mich ist die Existenz und Nutzbarkeit von btrfs - neben der Verfügbarkeit der Alltagstools für Office, Multimedia, Internet - ein Schlüsselfeature von Linux. Ob xfs jemals das liefern wird ... warten wir es ab. RH beginnt gerade erst mit der diesbezüglichen Entwicklung.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung