Login
Newsletter
Werbung

Thema: Google evaluiert Btrfs für Android

3 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
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.

  • 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.

    • 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.)

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung