Login
Newsletter
Werbung

Thema: Google evaluiert Btrfs für Android

17 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von lin am Mo, 21. August 2017 um 09:09 #

Btrfs ist wesentlich langsamer als ext4. Google sollte einfach warten bis die neuen Funktionen bei XFS angekommen sind (snapshots usw.) Das ist schneller und ausgereifter als Btrfs. Wer mit mdadm/lvm umgehen kann der braucht kein Raid im Dateisystem.

[
| Versenden | Drucken ]
  • 1
    Von Anonymous am Mo, 21. August 2017 um 09:23 #

    Und du glaubst, wenn man COW und Snapshots bei XFS implementiert sind, dann ist es schneller und ausgereifter als Btrfs? Es ist doch der Punkt, dass diese Features Btrfs verlangsamen. Schalte COW ab und es ist viel schneller. Aber wozu sollte man es dann verwenden?

    Und die neuen Featrures von Xfs müssen dann auch erst mal reifen.

    [
    | Versenden | Drucken ]
    • 1
      Von lin am Mo, 21. August 2017 um 09:59 #

      Cow ist bei XFS seit Kernel 4.9 experimentell Verfügbar. Bitte schalte es ein und wiederhole deine Aussage. Außerdem beschleunigt Cow das Dateisystem bzw. Kopiervorgänge. https://de.wikipedia.org/wiki/Copy-On-Write

      Das einzigste was ich an Btrfs wirklich richtig gut finde, ist die Snapshotfunktion.

      [
      | Versenden | Drucken ]
      0
      Von schmidicom am Mo, 21. August 2017 um 10:32 #

      Wie andere schon geschrieben haben ist CoW bereits seit Kernel 4.9 im XFS-Modul enthalten und xfsprogs kennt das ab Version "4.9.0". So viel konnte ich schon einmal auf deren cgit-Webseite herausfinden.

      Was ich aber immer noch nicht herausgefunden habe ist wir man das ohne neues Formatieren einschalten könnte.

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Aug 2017 um 10:33.
      [
      | Versenden | Drucken ]
      0
      Von Jan2 am Mo, 21. August 2017 um 11:32 #

      Ich habe längere Zeit auf einem Notebook btrfs und SELinux unter Fedora eingesetzt. Läuft sehr gut.

      Was Probleme laut den Rothüten machen soll ist die Kombination btrfs+selinux+container.
      Dort wird aber auf großes Blech gezielt, wird bei Android bestimmt nicht vorkommen.
      Ich denk mal die Rothüte wollen sich von XFS nicht trennen, bis jetzt wurde btrfs immer etwas zurückhaltend bei denen behandelt.

      Ich bin auch auf ext4 zurück, btrfs macht auf einen 32bit-3GB-Notbook (ja, in Not ,-)) einfach keinen Sinn. Da es ähnliche Funktionen wie ZFS bietet sollte man mit Arbeitsspeicher nicht geizen.

      Bin ja mal an euren Erfahrungen interessiert.

      Jan

      [
      | Versenden | Drucken ]
      • 0
        Von Jan2 am Mo, 21. August 2017 um 11:47 #

        Was ich noch vergessen habe:
        soweit mir bekannt gibt es noch keine btrfs-Treiber für Windows, dies war auch ein Grund zur Rolle-rückwärts.

        https://wiki.ubuntuusers.de/Linux-Partitionen_unter_Windows/
        http://www.ext2fsd.com/

        [
        | Versenden | Drucken ]
    0
    Von blubb am Mo, 21. August 2017 um 18:46 #

    Warten wir mal ab, ob XFS schneller und ausgereifter ist, wenn es bzgl. der Features gleichgezogen hat.
    Falls das passiert, ja dann wird es vermutlich wenig Argumente für btrfs geben.

    Wer mit mdadm/lvm umgehen kann der braucht kein Raid im Dateisystem.
    wrong

    Ich hatte dieses Wochenende wieder das Vergnügen. Ein raid1 mit recht alten Platten sollte ein Update bekommen, d.h. neue Platten, die auch noch ein bisschen größer sind (wobei der Teil war nicht so wild).
    Ich hab so abgekotzt, weil das alles zu bewerkstelligen irrsinnig umständlich und kompliziert war.
    Ok, zugegeben es hat es nicht unbedingt erleichtert, dass die neuen Festplatten 4k Sektoren (nativ) hatten, aber damit sollte es ja heute keine Probleme mehr geben, oder?

    Wie dem auch sei, mit btrfs wäre all das eine Sache von weniger als einer Stunde gewesen, inklusive dem eigentlichen (HW)-Tausch.
    Und nein, das ist keine Vermutung, ich habe genau das auch schon mit btrfs gemacht …
    (Mal ganz abgesehen davon, dass der sync des raid mind. einen Faktor 2 schneller war.)

    Insofern: feature-parity wird XFS für mich nur dann erreichen, wenn sie auch raid implementieren.
    mdadm und lvm fasse ich nicht mehr an, wenn es nicht sein muss, das artet nur in Frickelei aus …

    Verschlüsselung im FS hingegen sehe ich nicht als wirklich notwendig an, da tut es auch LUKS & Co.
    Sehe da nicht wirklich einen Vorteil das im FS unterzubringen.

    [
    | Versenden | Drucken ]
    • 0
      Von Robmaster1 am Mo, 21. August 2017 um 22:07 #

      Ich hatte bisher nie Probleme mit mdadm, weder wenn ich es manuell aufgesetzt habe noch wenn ich eine defekte Platte aus einer Synology NAS getauscht habe (Die verwenden auch mdadm). Aber jeder hat da sicherlich andere Erfahrungen gemacht. Auf großen Servern wird sowie ein Hardware-Raidcontroler verwendet.

      >>Verschlüsselung im FS hingegen sehe ich nicht als wirklich notwendig an, da tut es auch LUKS & Co.


      Das sehe ich anders, weil du für Luks immer eine unverschlüsselte Boot-Partition benötigst, was ein Sicherheitsrisiko sein kann. Mit dem neusten grub2 und ext4 ist eine Vollverschlüsselung möglich. Secure-boot ist nicht wirklich sicher.
      Wobei ich dir aber recht geben, ein recovery mit mdadm dauert ewig.

      [
      | Versenden | Drucken ]
      • 0
        Von blubb am Mo, 21. August 2017 um 22:47 #

        Mich nervt halt an mdadm, dass man ziemlich häufig in der Manpage rumsuchen muss. Das ist so ein umfangreiches und damit unübersichtliches Werk, dass macht wirklich keine Freude.
        Wenn man sich seine 5-10 Befehle eingeprägt hat, dann geht es halbwegs, aber wenn man dann mal etwas vom Standard (bzw. von den Standardbefehlen) entfernt machen muss, dann wird die Suche nach dem richtigen Weg teilweise übelst mühsam.
        Beispiel: es gab ein Problem mit den neuen HDDs wegen der 4k Sektoren (metadata 1.0, damals von der Distribution so angelegt), führte dazu, dass es zu Lesefehlern kam.
        Nun kam ich auf die glorreiche Idee die alten HDDs als neues, separates raid zur Verifikation zu nutzen (was übrigens mit btrfs auch nicht notwendig gewesen wäre), aber es ist gar nicht so einfach aus den alten HDDs ein neues raid mit den gleichen Daten zu machen, da die gerade eben noch sowieso verfügbar und auf dem korrekten Stand waren.
        Nicht, dass der Befehl elendig lange wäre, aber die richtigen Parameter rauszufinden war nicht so leicht, bzw. erst nach einigem Suchen im Internet.
        (Was übrigens auch wieder nervig war, denn 90% der Threads beziehen sich auf scheinbare Nichtigkeiten wie "wie tausche ich eine alte gegen eine neue Platte", scheint so, als bräuchten viele selbst dafür eine Anleitung, was nicht gerade für das Tool spricht.)

        Die Befehlsstruktur und Hilfe des `btrfs` tools sind da einfach deutlich überlegen. Man weiß man braucht ein Tool und nicht 3-4.
        Dieses eine Tool hat einige Unterbefehle, die bisher eigentlich alles konnten was ich benötigt habe (wobei es sicher mir unbekannte Anwendungszwecke gibt die nicht abgedeckt sind).
        Das ist einfach wesentlich eher straight-forward und besser strukturiert.

        Das sehe ich anders, weil du für Luks immer eine unverschlüsselte Boot-Partition benötigst, was ein Sicherheitsrisiko sein kann. Mit dem neusten grub2 und ext4 ist eine Vollverschlüsselung möglich. Secure-boot ist nicht wirklich sicher.
        Das ist prinzipiell richtig, aber dann kann immer noch grub2 manipuliert werden, oder?
        Zudem sollte das prinzipiell auch mit LUKS möglich sein, oder?
        (Entsprechende Unterstützung in grub2 vorausgesetzt.)

        [
        | Versenden | Drucken ]
2
Von wurzel am Mo, 21. August 2017 um 09:15 #

als überzeugter btrfs-Anhänger kann ich das Interesse von Google nur begrüßen.
Die würden garantiert auch einige gute Entwickler an das Projekt ransetzen und das kann btrfs nur gut tun. Als Entwickler für freie Software hat sich Oracle - freundlich formuliert - bislang nicht mit Ruhm bekleckert und ob und wann Red Hat mit seinem Alternativprojekt in die Füße kommt steht in den Sternen ..

[
| Versenden | Drucken ]
0
Von bierpilot am Mo, 21. August 2017 um 12:38 #

"Androids momentan eingesetztes Betriebssystem ist Ext4..." es ist doch eher vom Dateisystem die Rede... LG

[
| Versenden | Drucken ]
0
Von killx_den am Mo, 21. August 2017 um 13:33 #

Sehe darin eigentlich kein Problem, btrfs ist seit Ende 2013 auf allen SailfishOS Geräten im Einsatz und es läuft schnell und zuverlässig (spreche aus Erfahrung meines Jolla Phones und Jolla Tablets).

[
| Versenden | Drucken ]
  • 0
    Von inta am Mo, 21. August 2017 um 14:09 #

    Das stimmt so leider nicht. Nur das Jolla 1 setzt auf Btrfs als Dateisystem, schon beim Tablet sind sie soweit ich weiß wieder auf ext4 zurückgegangen. Auf dem Jolla C und Intex Aquafish kommt auf jeden Fall ext4 zum Einsatz. Btrfs hat auf dem Jolla 1 bei (fast) vollen Dateisystemen Probleme bereitet.

    [
    | Versenden | Drucken ]
0
Von irgendwer am Mo, 21. August 2017 um 15:13 #

Verschlüsselung ala F2FS / EXT4 wäre eine gute Sache. Darauf warte ich auch noch.

[
| Versenden | Drucken ]
  • 0
    Von irgendwer am Mo, 21. August 2017 um 15:16 #

    PS: Android könnte der Grund sein, weshalb das auch genau so für btrfs in zu F2FS und EXT4 kompatibler Form kommen könnte. Das hieße nämlich die Android-Tool-Landschaft wäre schon darauf vorbereitet. Das sind somit sehr gute News. Hoffentlich kommt's auch so - also es sieht jemand als Ansporn, das wirklich umzusetzen.

    [
    | Versenden | Drucken ]
0
Von jb_ am Mo, 21. August 2017 um 23:08 #

Google soll doch Oracle etwas Geld spendieren, damit die endlich mal die Lizenz von ZFS ändern :).

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