Login
Newsletter
Werbung

Thema: Btrfs unterstützt Swap-Dateien

19 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
2
Von Antiquities am Fr, 14. Dezember 2018 um 11:10 #

ich verwende btrfs seit Jahren auf HD und USB3 Devices ohne Probleme und mit hoher Performance, Sicherheit und die Möglichkeit einfach ein Filesystem an ein anderes anzuflanschen, um die Kapazität zu erhöhen.

[
| Versenden | Drucken ]
  • 0
    Von blablabla233 am Do, 27. Dezember 2018 um 19:08 #

    Genau das sagte ich den RZ-Leuten auch und erbrachte mit meinem USB3-Stick auch den Beweis...aber die lachten nur. :?

    [
    | Versenden | Drucken ]
1
Von Btrfs am Fr, 14. Dezember 2018 um 11:54 #

"Einen Dämpfer erhielt diese Feststellung allerdings Mitte des vergangene Jahres, als Red Hat ankündigte, Btrfs nicht weiter zu unterstützen. Der Grund dafür liegt in der Tatsache, dass Btrfs im Zusammenspiel mit Docker Probleme bereiten kann und nicht mit dem bei Red Hat eingesetzten SELinux zusammenarbeitet."

Ich bin immer noch der Meinung dass Red Hat der Aufwand des Zurückportierens auf ihren Kernel zu groß ist, zumindest was BTRFS betrifft

Nach der Ankündigung von Red Hat habe ich ein Diagramm gesehen (leider finde ich es nicht mehr auf die schnelle) welches zeigt dass Red Hat seit Jahren (!) nichts mehr zu BTRFS beigetragen hat, sondern hauptsächlich Suse und Facebook (?).

Vielleicht ändert sich das dank der Übernahme durch IBM, wer weiß.

[
| Versenden | Drucken ]
  • 1
    Von Jan2 am Fr, 14. Dezember 2018 um 13:41 #

    Red Hat hat sich gegen BTFS entschieden weil BTFS mit SELinux
    nicht funktioniert.
    RedHat macht Statis und bohrt XFS auf.
    Und da Suse nicht SELinux macht...

    F26 & F27 habe ich auch auf BTFS laufen lassen und keine
    Probleme bemerkt.

    [
    | Versenden | Drucken ]
    1
    Von MichaelK am Fr, 14. Dezember 2018 um 14:54 #

    Btrfs ist obsolet. Ist jetzt erst halbwegs in den Regionen, wo ZFS schon seit Jahren ist (und schon ZFS gilt als "veraltet" bzw. in mancher Hinsicht nicht mehr vernünftig weiterentwickelbar).
    Andererseits kommt auch Konkurrenz hinzu.
    bcachefs von der Linux Seite.
    HAMMER2 von der (Dragonfly-)BSD-Seite

    nichts mehr zu BTRFS beigetragen hat

    Ich glaube auch, Btrfs leidet etwas unter der eigenen Codequalität. Da müsste man mal einiges gerade ziehen. Und da das Aufwand mit sich bringt und Du Dich ja auch mit den anderen Entwicklern darüber abstimmen musst, stellt sich halt die Frage: Warum?

    Die Frage gäbe es vielleicht nicht, wenn Btrfs alternativlos wäre. Aber dem ist ja nicht so.

    [
    | Versenden | Drucken ]
    • 1
      Von john am Fr, 14. Dezember 2018 um 18:13 #

      Wenn es für Btrfs eine Alternative gäbe, würde ich sie nutzen.
      Eine Zeit lang habe ich mal ZFS genutzt, doch das Kernelmodul hat sich beim Updaten zuweilen verabschiedet ;)
      Auf Bcachefs hingegen werde ich gerne wechseln, wenn es denn mal stabil ist. (Und ich mich zur Migration meines NAS aufraffen kann).

      [
      | Versenden | Drucken ]
      • 0
        Von MichaelK am So, 16. Dezember 2018 um 14:44 #

        Eine Zeit lang habe ich mal ZFS genutzt, doch das Kernelmodul hat sich beim Updaten zuweilen verabschiedet ;)
        Wenn Du Dein System mit Vorsatz kaputt machst, kann das beste Filesystem nix machen.

        Auf Bcachefs hingegen werde ich gerne wechseln, wenn es denn mal stabil ist.

        Ja. Bcachefs ist eher was für die Zukunft.
        Aber wenigstens scheint es eine zukunft zu haben. Im Gegensatz zu Btrfs.

        (Und ich mich zur Migration meines NAS aufraffen kann).
        Für Anwendungen wie NAS ist doch ZFS eigentlich gesetzt. Optimalerweise zusammen mit FreeBSD.

        [
        | Versenden | Drucken ]
        • 0
          Von john am Mo, 17. Dezember 2018 um 16:57 #

          Wenn Du Dein System mit Vorsatz kaputt machst, kann das beste Filesystem nix machen.
          Updaten ist also gleich "mit Vorsatz kaputtmachen."
          Wenn man ZFS benutzt, darf man also nicht updaten. Gut zu wissen.

          Ja. Bcachefs ist eher was für die Zukunft.
          Aber wenigstens scheint es eine zukunft zu haben. Im Gegensatz zu Btrfs.
          Unglücklicherweise hat bcachefs keine Gegenwart.
          Ich würde es ja jetzt benötigen, doch es ist noch nicht stabil.
          Wenn bcachefs und ZFS also ausscheiden, was bleibt dann wohl noch übrig?

          Für Anwendungen wie NAS ist doch ZFS eigentlich gesetzt. Optimalerweise zusammen mit FreeBSD.
          Würde ich BSD verwenden, wäre das Dateisystem darauf sicherlich ZFS - wäre da nicht die Send-And-Receive-Funktion, für die entweder nur ZFS oder nur Btrfs verwendet werden können. Ich müsste also meine Workstation ebenfalls mit ZFS betreiben. (Und wahrscheinlich doppeltem RAM)

          Stell dir mal vor, ich möchte meine Workstation updaten und muss mir anhören, das mache man doch nicht, das wäre ja schädlich für ZFS ????

          [
          | Versenden | Drucken ]
          • 0
            Von MichaelK am Di, 18. Dezember 2018 um 13:52 #

            Updaten ist also gleich "mit Vorsatz kaputtmachen."
            Das hast Du missverstanden und ich hatte mich aber auch nicht ganz klar ausgedrückt.

            Klar muss man ab und zu mal updaten. Aber man muss auch gucken, dass das System läuft. Vor dem Update guckt man halt in die Release-Notes und schaut bei den Known-issues. Außerdem sollte das System eine gewisse ZFS-Unterstützung mitbringen.
            Wenn man also irgendeine Linux-Distribution nimmt, die ZFS so überhaupt nicht supportet und man das dann irgendwie reinbastelt, ist halt die chance hoch, dass so etwas passiert.
            Du würdest ja auch nicht auf die Idee kommen btrfs in ein Redhat Linux reinzubasteln.

            Unglücklicherweise hat bcachefs keine Gegenwart.
            Richtig. Das haben Ausblicke so ansich.

            Wenn bcachefs und ZFS also ausscheiden, was bleibt dann wohl noch übrig?
            Ich will gar nicht in Abrede stellen, dass btrfs für bestimmte Szenarien eine Lösung sein kann bzw. nicht auch von Leuten benutzt wird. Ich denke nur nicht, dass aus btrfs das werden wird, was vor Jahren angekündigt wurde.: The next-gen-Linux-Filesystem welches auch in der Breite eingesetzt wird.

            Und das sehe ich so eben nicht. Zumal OpenZFS wesentlich professioneller aufgestellt ist als btrfs.

            Würde ich BSD verwenden, wäre das Dateisystem darauf sicherlich ZFS - wäre da nicht die Send-And-Receive-Funktion, für die entweder nur ZFS oder nur Btrfs verwendet werden können. Ich müsste also meine Workstation ebenfalls mit ZFS betreiben.
            Vorab. Auch ich schätze die send/receive Funktionalität sehr. Allerdings sehe ich die enge Bindung ans Dateisystem problematisch. Genau aus den Gründen, wie du sie beschreibst. Ich würde solche Sachen wenn möglich immer anders realisieren.

            Übrigens. Was die Kompatiblität angeht bist Du mit ZFS sogar besser dran. btrfs ist ja nur zu sich selbst kompatibel. ZFS-Pools aber im Prinzip zu jeder ZFS-Implementation nach dem OpenZFS-Standard.
            Wenn Du also ein MacOS mit ZFS hast oder ein Linux mit ZFSonLinux, kannst Du durchaus ein send/receive zu der ZFS-Variante von FreeBSD machen.

            Bei btrfs bist Du an Linux gebunden. Evtl. kriegst Du mit WinBtrfs noch Windows abgedeckt.

            (Und wahrscheinlich doppeltem RAM)
            ZFS ist jetzt nicht RAM-intensiver als andere Dateisysteme dieser Größenordnung. Es gibt allerdings Features die tatsächlich viel RAM benötigen und wohl ZFS auch diesen Ruf eingebracht haben. Wie zum Beispiel Deduplication. Darum wird das Feature auch häufig gar nicht eingeschaltet. Deduplication ist tatsächlich relativ ineffizient implementiert und einer der problematischen Punkte bei ZFS.

            [
            | Versenden | Drucken ]
      0
      Von Randy Andy am Sa, 15. Dezember 2018 um 11:48 #

      Na da muss ich ja fast schon froh sein, über dieses Statement.
      Hatte ich mir doch seit der Ankündigung von RH fast schon etwas Sorgen gemacht, schliesslich nutze ich BTRFS fast von anfang an und möchte es nicht mehr missen.

      Nun aber nach deinem Post: Btrfs is obsolete brauche ich mir aber keine Sorgen mehr machen und bin mir sicher die Geschichte wiederholt sich wie nach Andy Tanenbaums Post in comp.os.minix: LINUX is obsolete.

      Danke dafür! ;-)

      [
      | Versenden | Drucken ]
      • 0
        Von MichaelK am So, 16. Dezember 2018 um 14:47 #

        wie nach Andy Tanenbaums Post in comp.os.minix: LINUX is obsolete.

        Technisch hatte Tanenbaum ja durchaus Recht. Linux ist ja nicht deshalb erfolgreich gewesen, weil man etwas Neues und Innovatives gebaut hat. Linux war von Anfang an ein UNIX-Klon. Deshalb gabs auch relativ schnell Programme für Linux. Die waren halt einfach zu portieren.

        [
        | Versenden | Drucken ]
        • 0
          Von irgendwer am Mo, 17. Dezember 2018 um 21:45 #

          Linux ist kein Unix-Klon. Es ist ein eigenständiges, nicht aus dem ursprünglichen Unix-Code hervorgegangenes, Posix-kompatibles Betriebssystem. Daher lassen sich Anwendungen nutzen, die Posix-Schnittstellen voraussetzen bzw. die die Posix-API-Verwenden.

          Es lassen sich auch Windows-Anwendungen nutzen, weil einige Windows-APIs (z.B. win32) implementiert sind. Dennoch ist es kein Windows-Klon.

          Es ist auch nur deshalb kein offizielles Unix, weil man als nicht von der AT&T-Codebasis abgeleitetes Werk (ala *BSD) ein kommerzielles Zertifikat benötigt, um sich so nennen zu dürfen. Das ist offensichtlich kein Ziel von Linux – man verzichtet schlicht darauf. Ist ja auch nötig: als aktuell am meisten verbreitetes System hängt der Erfolg hier nicht von einem kaufbaren Trademark ab. Das überlässt man anderen wie IBM, Microsoft oder Apple.

          Hehe, apropos, vielleicht trägt ja demnächst IBM RHEL ein offizielles Unix-Logo... :-P
          (ne, ich denke nicht, aber wer weiß... )

          Apropos Posix. Auch da ist Linux mitunter der Norm entsprechend, wenn man das nicht bewusst anders macht (z.B. weil man sich für die Standard-Shell "bash" entscheidet) und somit auch eher nicht aus technischem Grund, sondern wohl eher weil man sich die Zertifizierungskosten gespart hat. ... naja und weil man an Stellen, an denen sich Posix und GNU beißen als GNU/Linux ... naja... ich mein ja nur... ;-)

          [
          | Versenden | Drucken ]
          • 0
            Von MichaelK am Di, 18. Dezember 2018 um 14:07 #

            Linux ist kein Unix-Klon.
            Doch. Im Ursprung schon.

            Es ist ein eigenständiges, nicht aus dem ursprünglichen Unix-Code hervorgegangenes
            Hat niemand etwas anderes behauptet.

            Wenn das Wort Klon missverständlich ist, kann man es auch Nachbau nennen. Wird auch an dem deutlich was Du selbst sagst:

            Posix-kompatibles Betriebssystem.
            Übrigens ist die POSIX-Kompatibilität durchaus lückenhaft.

            Es ist auch nur deshalb kein offizielles Unix, weil man als nicht von der AT&T-Codebasis abgeleitetes Werk (ala *BSD) ein kommerzielles Zertifikat benötigt, um sich so nennen zu dürfen.
            Abgeleitet muss es nicht sein.
            UNIX ist eine Marke die geschützt ist.
            Ein Zertifikat alleine reicht natürlich nicht. Um das Zertifikat zu bekommen, musst Du auch ein Standard-Prozedere durchlaufen.

            Aber so hoch aufgehängt wollte icjh den Begriff Unix an der Stelle gar nicht aufgehängt wissen. Es war mehr als die allgemeine Beschreibung eines, wenn man es so will, unixoiden Systems.

            Und da war es zweifelsohne so, dass Linux' Vorbild die UNIX-Systeme waren, die es gab.

            [
            | Versenden | Drucken ]
1
Von MichaelK am Fr, 14. Dezember 2018 um 12:52 #

Was wirklich bitter ist, ist dass es mit ZFS schon seit vielen Jahren eine funktionierende Lösung gibt und diese aus politisch/lizenzrechtlichen Gründen nicht in den Linux-Kernel Einzug halten kann.

Zwar kommt inzwischen mit ZFSonLinux etwas Bewegung in die Sache. Aber wie lange mussten die Linux-Anwender warten?
Und wie gesagt. Es gab keine technischen Gründe. Das ist allein der GPL geschuldet.

Interessant ist das deshalb, weil nicht wenige GPL-Verfechter ja gerne mal gegen restriktive proprietäre Lizenzen schießen so aber selbst eigentlich nicht wirklich besser sind.

[
| Versenden | Drucken ]
  • 0
    Von kamome umidori am Fr, 14. Dezember 2018 um 15:17 #

    > Das ist allein der GPL geschuldet

    Oder aber der beanstandeten Passage der CDDL; oder der Interpretation der GPL _Einiger_ diesbezüglich.

    So klar ist das also nicht – schade auf jeden Fall!

    [
    | Versenden | Drucken ]
    0
    Von Hans-Wurst am Sa, 15. Dezember 2018 um 02:15 #

    "Das ist allein der GPL geschuldet."

    Nein, der CDDL (bzw. SUN).

    Die GPL existierte schon - und zwar wesentlich länger - zum Zeitpunkt des Veröffentlichung. Eine Kompatibilität mit der GPL hätte man also berücksichtigen können wenn SUN das gewollt hätte - haben sie offensichtlich aber nicht. So liegt die Schuld mit Sicherheit nicht auf Seiten der GPL.
    Davon abgesehen ist es - trotz Oracle - immer noch realistischer die Lizenz eines Paketes zu ändern als all jene eines gesammten Ökosystems (Linux).

    [
    | Versenden | Drucken ]
    • 0
      Von Kaibadergroße am Sa, 15. Dezember 2018 um 13:16 #

      Schon wieder einer der die GPL Intention verdreht. GPL Code möchte man nur mit GPL Code verheirateten, alles andere ist nicht gewollt. Warum sollen Lizenzen die in anderen Bereichen freier sind, sich da beugen? Ich bin froh das meine Weihnachtsgeschenke nicht unter der GPL fallen.

      [
      | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung