Login
Newsletter

Thema: Welches Dateisystem nutzen Sie bevorzugt bei Ihrem Desktop?

74 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Nur ein Leser am Fr, 23. November 2018 um 14:12 #

Ich halte mich da seit openSUSE Leap an die Empfehlung von SUSE:
/ mit BTRFS
/home mit XFS

Da für / Snapshots angelegt werden, ist ein schneller Rollback in alte Stände möglich, snapper legt diese Snapshots z.B. jedesmal bei wichtigen Konfigurations- oder Paketänderungen an. Ist praktisch.

Für /home wäre ich auch mit EXT4 zufrieden, habe da keine schlechten Erfahrungen gemacht. Aber da XFS empfohlen wird (und recht performant sein soll), hab ich es auch so übernommen. Kann auch nicht sagen, das ich damit schlechte Erfahrungen gemacht hätte.

Ist bei mir allerdings alles auf dem Level eines Home-Users, also keine speziellen Anforderungen oder Konstellationen.

  • 0
    Von mosu am Fr, 23. November 2018 um 16:06 #

    Bei mir ähnlich, allerdings habe ich für home ext4 beibehalten. Den Vorteil von BTRFS sehe ebenfalls in der Wiederherstellungsmöglichkeit, die bei oS hervorragend implementiert ist.
    Bei den als Zweit- und Drittinstallation laufenden Neon und Debian (Gnome) dementsprechend ext4 für / und /home.

    1
    Von V_180_358 am Fr, 23. November 2018 um 17:11 #

    Wenn ich jetzt mal so naiv frage:
    Was macht ihr eigentlich mit euren Rechnern, daß ihr so gesteigerten Wert auf ein "Rollback" legt?

    Ich habe einen Rechner mit Debian "unstable" exakt 6 Jahren, 2 Monaten, 9 Tagen laufen gehabt, damit täglich gearbeitet und war nie in der Verlegenheit irgend etwas zurückrollen zu müssen. Und wenn nicht eine neue Rechner-Generation an der Zeit gewesen wäre würde die o.g. Kiste immer noch ihren Dienst verrichten.

    • 0
      Von Debian unstable am Fr, 23. November 2018 um 19:31 #

      Gerade die letzten Tage mal wieder: System upgedated, reboot und sobald X startet friert der Rechner ein. Reproduzierbar und nicht behebbar.

      Rollback auf Systemstand vom Tag zuvor hat es dann geflickt. Seitdem habe ich das System jedoch erstmal nicht upgedated.

      Debian Stable auf Lenovo Laptop

      0
      Von mosu am Fr, 23. November 2018 um 21:33 #

      Irgendwie fällt mich doch immer wieder der Spieltrieb an (wenn schon keine Computerspiele). Seit ich mir allerdings zwei Spielpartitionen eingerichtet habe, bräuchte ich eigentlich kein Snapper mehr.

      0
      Von Klappstulle am Fr, 23. November 2018 um 23:48 #

      Das frage ich mich auch jedes mal, wenn in Diskussionen dieses Feature so penetrant überbetont wird.

      • 0
        Von Nur ein Leser am Sa, 24. November 2018 um 15:02 #

        Im Gegensatz zu den meisten anderen Features von BTRFS, die ich als Home-User quasi nie brauchen werde, ist der Nutzen der Snapshots/Rollbacks jedem Laien sofort offensichtlich.

        Deshalb wird es vermutlich ganz gerne betont, auch von mir.

      2
      Von Anonymous am Sa, 24. November 2018 um 07:45 #

      So eine Rollback-Funktion muss man ja nicht ständig nutzen, damit sie einen Sinn hat. Du erstellst ja hoffentlich auch Backups, obwohl deine Festplatte nicht alle 6 Wochen planmäßig abraucht.

      Die Rollback-Funktion sichert bei openSUSE nicht das Home-Verzeichnis, daher ersetzt sie das Backup nicht, und im Zweifelsfall installiert man eben das Betriebssystem neu + alle Pakete, die man noch zusätzlich installiert hatte.

      Das kostet einen aber auch gleich mal ein, zwei Stunden. Der Charme der Rollback-Funktion ist dass man in weniger als 5 Minuten wieder arbeitsfähig ist. Egal ob das die eigene Blödheit war oder etwas was unausweichlich ist, also man später dann nochmal richtig machen muss. Das kann man dann wunderbar auf's Wochenende vertagen.

      • 0
        Von ebenMal am Sa, 24. November 2018 um 17:02 #

        Das kostet einen aber auch gleich mal ein, zwei Stunden. Der Charme der Rollback-Funktion ist dass man in weniger als 5 Minuten wieder arbeitsfähig ist. Egal ob das die eigene Blödheit war oder etwas was unausweichlich ist, also man später dann nochmal richtig machen muss. Das kann man dann wunderbar auf's Wochenende vertagen.
        Und erlaubt ohne jede probleme die ganzen Kisten wieder zu restaurieren, die man bei Kumpels oder Opa aufgestellt hat und die sich diese *Anfänger* mit exotischen Versuchen zerlegt haben.
        Ich habe keine Lust jedes Mal einen ganzen Abend bei denen nach Fehlerursachen zu suchen.

        Frage: was machst du da 5 Minuten?
        Ein str-alt-f1 + snapper list + snapper rollback ## + reboot
        läuft doch in 90 Sekunden durch ?

    1
    Von Markus B. am Fr, 23. November 2018 um 17:15 #

    Bei XFS aber auf jeden Fall auch eine USV verwenden...

    • 0
      Von LukaDuka am Fr, 23. November 2018 um 17:22 #

      Warum ist eine USV bei XFS auf jeden Fall notwendig? Eine Quellangabe wäre echt super.

      • 2
        Von glasen am Fr, 23. November 2018 um 20:21 #

        XFS schützt Standardmäßig per Journal nur die Integrität der Metadaten (Größe und Namen der Dateien), der Inhalt kann aber beschädigt werden. XFS füllt dann die beschädigte Datei einfach mit binären Nullen auf:

        XFS: FAQ

        Aus diesem Grund wurde in XFS Copy-On-Write integriert. Nur weiß ich nicht ob dieses immer noch experimentell ist.

        • 0
          Von LukaDuka am Fr, 23. November 2018 um 21:13 #

          Danke für die Quellenangabe, jetzt verstehe ich auch den technischen Hintergrund. Das ist korrekt, und das Verhalten ist "by design". Soweit ich mich korrekt erinnere, schreibt XFS die Datei erst wenn sie vollständig aus dem Speicher auf den Datenträger geschreiben werden kann. Das ist der Grund warum XFS keine Defragmentierung benötigt, es versucht die Datei in einem Stück anzulegen.

        0
        Von haha am Sa, 24. November 2018 um 18:01 #

        Ich hatte vor 10 Jahren mal alle gängigen Dateisystem per Netzsteckerziehen getestet.

        XFS war das einzige, welches immer wieder hochkam, allerdings war es die Kernel-Implementierung von Mandrake. Zu diesem Zeitpunkt jammerten ebenso Suse & Co über die XFS-Stabilität ...

        • 0
          Von Markus B. am Sa, 24. November 2018 um 19:09 #

          XFS verkraftet Stromausfälle nur scheinbar gut. Das Problem ist, dass Dateiinhalte noch nicht geschrieben wurden, obwohl Name, Datum und Größe fieserweise auf dem aktuellen Stand sind.

          Da hat man dann Dateien, die inhaltlich kaputt sind, bemerkt dies jedoch erst, wenn man sie mal wieder öffnet, also u. U. viel später. Im schlimmsten Fall so spät, dass man dann schon alle seine Backups damit überschrieben hat.

          Am ehesten merkt man es noch bei der boot- oder root-Partition, wenn es das System beim Starten aufprackt.

      0
      Von Nur ein Leser am Sa, 24. November 2018 um 14:59 #

      Ich habe das auf Laptops laufen, ist somit quasi gewährleistet.
      Desktops habe ich gar nicht mehr.

      Aber danke für den Hinweis.

    0
    Von frankenmichl am Di, 27. November 2018 um 09:04 #

    Geht mir ganz ähnlich. Alles war irgendwie zum System gehört, packe ich auf btrfs. Wer schonmal ein Update hatte, das einem das System kaputt gemacht hat, wird sich freuen.
    Und nicht nur für /home, sondern für Datenpartitionen generell, verwende ich XFS. Das dürfte das stabilste Dateisyystem sein.

    • 0
      Von Heiz-Profi am Di, 27. November 2018 um 11:09 #

      Was benutzt Du denn, dass Dir eine "Update" die Installation kaputt macht?

      Oder sitzt nicht doch das eigentliche Problem auf Armlänge vor dem Rechner?

      • 0
        Von Verfluchtnochmal-05995bd7b am Mi, 5. Dezember 2018 um 15:49 #

        Genau so dumm kannst du auch gegen RAID argumentieren weil deine Festplatte sind 6 Jahren durchläuft und wenn sie das morgen nicht mehr tut stehst du da mit heruntergelassener Hose

        Probleme vor dem Monitor sind User die nicht drüber nachdenken was alles schief gehen kann und dann wenn es schief geht voller Panik in Foren auftauchen und von anderen erwarten dass sie ihr scheiss Problem am besten sofort lösen sollen

0
Von kraileth am Fr, 23. November 2018 um 14:25 #

Seit einigen Jahren eigentlic nur noch ZFS. Bei den herkömmlichen Dateisystemen fehlt mir inzwischen einfach etwas (und UFS konnte man aus irgendwelchen Gründen so oder so gar nicht auswählen). Boot Environments sind unglaubliche praktisch und Snapshots, send/receive, die Flexibilität von Datasets, die eingebaute Volume-Manager-Funktionalität oder auch "Kleinigkeiten" wie LZ4-Kompression machen das Dateisystem zu einem echten Hammer, an dem ich nicht mehr vorbei komme. Nur auf Systemen mit wenig RAM setze ich noch primär auf UFS. Und falls es eine Linux-Kiste sein soll, dann meist Ext4 für Root und ZFS für den Rest.

Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Nov 2018 um 14:26.
2
Von Tiggez am Fr, 23. November 2018 um 14:32 #

Schnell, simpel und stabil.

1
Von SuperMän am Fr, 23. November 2018 um 16:30 #

für / immer btrfs und für /home ext4.
Ein Rollback ist blitzartig gemacht wenn mal wieder ein Update irgendwas zerschießt.
Seitdem die Kombination btrfs-snapper von Opensuse zur Verfügung gestellt wird installiere und update ich erheblich entspannter.

Auf was man allerdings achten muss: Partition nicht volllaufen lassen. Das mag btrfs immer noch nicht.

  • 0
    Von Jürgen Sauer am Fr, 23. November 2018 um 16:56 #

    Warum eigentlich /home als ext4 ?
    ist das am Desktop mit einer SSD nicht ziemlich "unhandlich", da der wervolle ssd platz ineffizient genutzt wird.
    Warum nicht /home als subvolume einbinden ?

    Im Betrieb haben wir /home vom Server/Cluster als NFS (BTRFS auf server) und führen $HOME/[.local|.cache|.config|.thunderbird] als lokale /user/$name/[local|cache|config|email] subvolumes vom Stammvolume. (Automounter bzw. systemd mountd lassen grüßen)

    Das entlastet den Server vom Irrsin der modernen Desktops (KDE und Gnome) XFCE4 braucht diese Extrawurst nicht.

    • 0
      Von blubb am Fr, 23. November 2018 um 17:34 #

      Hat man denn einen Vorteil, wenn man X subvolumes einführt?
      Eigentlich reicht doch eins, oder? d.h. /user/$name/local-data (o.ä.)
      Im home Verzeichnis dann einfach entsprechend links anlegen, z.B.
      $HOME/.config -> /user/$name/local-data/.config

      Macht es einfacher snapshots zu ziehen (falls gewünscht) und reduziert die Abhängigkeiten bei den mounts.
      Zumindest sehe ich bei eurer Lösung keinen Vorteil.

      Übrigens gibt es für ext4 auf /home schon Gründe. btrfs geht nämlich mit Speicherplatz recht verschwenderisch um.
      Stört mich persönlich aber nicht, daher nutze ich auch auf /home btrfs, allerdings dennoch abgetrennt wegen raid1, da glaube ich eine Zuordnung von devices an spezielle subvolumes meines Wissens nicht geht (und im Endeffekt auch einem separaten Dateisystem entspricht).

      • 0
        Von Jürgen Sauer am Fr, 23. November 2018 um 17:41 #


        Hat man denn einen Vorteil, wenn man X subvolumes einführt?
        Eigentlich reicht doch eins, oder? d.h. /user/$name/local-data (o.ä.)

        Vorteile bringt das keine.

        Jedoch leider funktionierte das "Ein-Linken" nicht zuverlässig, da haben die Desktop Systeme (KDE, Gnome, Cinammon und Konsorten) immer wieder gern mal die links durch Verzeichnise auf dem NFS Server freimütig ersetzt. Ergebnis: gelegentliche DDOS auf den Server beim Login der Kollegen ...

        Auch nervt systemd mit Bugs und Instabilitäten rum, wenn man die mounts "nur" in der fstab einträgt. Aber das ist ein anderes unendliches nerv Thema ...

        • 0
          Von Jürgen Sauer am Fr, 23. November 2018 um 17:55 #

          Nachtrag:

          und die Beachtung der fredesktop.org Environment Variable

          $XDG_*

          ist auch sehr optional... bisweilen kann man die setzen wie man Lustig ist und ... nix geht wie in docs beschrieben -> wieder alles auf dem NFS $HOME/.local ...

          0
          Von blubb am Fr, 23. November 2018 um 19:07 #

          Jedoch leider funktionierte das "Ein-Linken" nicht zuverlässig, da haben die Desktop Systeme (KDE, Gnome, Cinammon und Konsorten) immer wieder gern mal die links durch Verzeichnise auf dem NFS Server freimütig ersetzt. Ergebnis: gelegentliche DDOS auf den Server beim Login der Kollegen ...
          hm ok, da hatte ich (KDE Nutzer) bislang keine Probleme, funktioniert seit mehreren Jahren problemlos.
          Ist halt nur etwas müßig am Anfang das alles einzurichten, aber dann läuft es, zumindest bei mir.
          Wie es mit anderen Desktops aussieht weiß ich natürlich nicht, kann sein, dass es da Probleme gibt.
          Auch nervt systemd mit Bugs und Instabilitäten rum, wenn man die mounts "nur" in der fstab einträgt. Aber das ist ein anderes unendliches nerv Thema ...
          Ja, kann ich nachvollziehen.
          Ich mag systemd wirklich, aber für mounting hab ich mir eigene units geschrieben, die einfach nur funktionieren. Automatisch lasse ich da nix erledigen, funktioniert meiner Erfahrung nach nicht gut.
          Wobei es auch schon ein paar Jahre her ist, dass ich das getestet habe.

      0
      Von Anonymous am Sa, 24. November 2018 um 16:08 #

      openSUSE setzt ja BTRFS für / und XFS für /home ein, und da habe ich mal die Begründung gelesen, dass sich die Dateien im Home-Verzeichnis einfach zu oft ändern und generell oft recht groß sind. Also wenn man eben mal ein Video auf die Platte zieht und später wieder runter, dann hat die BTRFS Snapshot-Funktion tendenziell zweimal sehr viel Spaß und braucht dann auch den Plattenplatz des Videos, solange dazwischen liegende Snapshots nicht entfernt werden.

      Außerdem ist so ein Snapshot kein Backup. Wenn das Dateisystem oder die Platte komplett den Geist aufgeben, dann bringt einem so ein Snapshot gar nichts. Das was in / liegt, kann man mit einer Neuinstallation und etwas Arbeit wieder herstellen. Das unter /home nicht. Daher ist es vielleicht auch ganz gut, wenn Benutzer nicht auf die dumme Idee kommen, kein Backup zu brauchen.

      • 0
        Von blubb am So, 25. November 2018 um 11:47 #

        openSUSE setzt ja BTRFS für / und XFS für /home ein, und da habe ich mal die Begründung gelesen, dass sich die Dateien im Home-Verzeichnis einfach zu oft ändern und generell oft recht groß sind. Also wenn man eben mal ein Video auf die Platte zieht und später wieder runter, dann hat die BTRFS Snapshot-Funktion tendenziell zweimal sehr viel Spaß und braucht dann auch den Plattenplatz des Videos, solange dazwischen liegende Snapshots nicht entfernt werden.
        Da sind subvolumes von Vorteil. Wenn du nun z.B. /home als subvolume einführst und dann von / einen snapshot erstellst sind Änderungen in /home nicht inbegriffen, dafür muss man einen separaten snapshot erstellen.
        Daher habe ich z.B. den download Cache vom Paketmanager als separates subvolume definiert, was den einzigen Sinn hat, dass dieses Verzeichnis beim snapshotten (gibt es das als Verb? xD) nicht mitgenommen wird.
        Das spart immens viel Speicherplatz.
        Wobei ich persönlich keine Snapshots des /home Volumes erstelle, was aber eher damit zusammenhängt, dass ich die Daten eher anders absichere bzw. falls notwendig auf eine externe Platte auslagere.
        Außerdem ist so ein Snapshot kein Backup. Wenn das Dateisystem oder die Platte komplett den Geist aufgeben, dann bringt einem so ein Snapshot gar nichts.
        Natürlich ist es das, zumindest wenn man damit richtig umgeht.
        Den Snapshot auf ein separates (i.e. externes) Laufwerk kopieren und schon hat man sein Backup.
        Kann man bei HW Ausfall problemlos wieder herstellen.
        Aber selbst lokal ist ein Snapshot ein Backup. Keines das gegen HW Ausfall schützt, aber zumindest ja (wie oben erwähnt) gegen SW Fehler (fehlgeschlagene Updates etc.).

    2
    Von Frühstücksbrötchen am Fr, 23. November 2018 um 18:02 #

    ...wenn mal wieder ein Update irgendwas zerschießt...

    Was bei der häufig katastrophalen Qualität der openSUSE-Updates (siehe die 3 Kernel-Updates im Oktober) ja auch dringend notwendig zu sein scheint.
    Ich ziehe eine Distribution vor, die mich nicht zu so einer Arbeitsweise zwingt.

    • 0
      Von Lord am Sa, 24. November 2018 um 10:28 #

      Hab ich was verpasst, ich habe >10 Opensuse Installationen am Laufen, cih hab in 10 Jahren kein Rollback gebraucht. Auf meiner persönlichen Kiste läuft Tumbleweed, auch da noch kein Problem gehabt, ausser, dass mal die Festplatte durch die Kernelupdates voll lief, weil der Dienst, der alte Kernels runterschmeist nicht aktiviert war.

      Allerdings nutze ich keine Nvidia Karte, da hätte man laufend ein Rollback benötigt, weil die Treiber mal wieder nicht funktioniert haben.

      1
      Von Nur ein Leser am Sa, 24. November 2018 um 15:07 #

      Bitte lass doch diese maßlosen Übertreibungen, das hier ist keine Umfrage, welche Distributionen man toll findet und welche doof.

      Ich nutze openSUSE seit 13.1 und die Snapshot-Funktionen seit Leap.
      Ich habe noch nie aufgrund irgendwelcher missglückten Patches mein System nicht mehr starten können (habe aber auch Intel-Grafik, kein Nvidia).
      Aber es ist gut zu wissen, das ich es könnte - einfach im Grub einen alten Snapshot zum Starten auswählen. Das ist super gemacht, das wird man doch wohl sagen dürfen.

      • 1
        Von Frühstücksbrötchen am Sa, 24. November 2018 um 15:37 #

        Maßlose Übertreibung?
        Nicht ich habe das mit den immer wieder zerschossenen SUSE-Updates in den Ringe geworfen. Aber eine paar Erfahrungen konnte ich seit Ende September schon sammeln.

        30.09. nach dem (Kernel?)-Update sind im GRUB alle fremde OS fort aus dem GRUB-Menü
        Da war der Rechner das erste mal bei mir.
        Und darauf folgten:
        09.10. kaputter kernel kernel-default-4.12.14-lp150.12.19.2 bootet nicht, u.a. wenn der Rechner als Host für Virtualbox dient, openSUSE als Gast in Virtualbox bootet grundsätzlich nicht
        13.10. O-Ton Marcus Meissner: Wir haben schon mehr Berichte dazu, das lag es an den virtualbox Treibern.
        (Dumme Sache aber, wenn die Installation weder als Gast in einer VB, noch als Host für eine solche läuft)
        16.10. kernel-default-4.12.14-lp150.12.22.1.x86_64 noch kaputter, zerstört erneut GRUB
        09.11. kernel-default-4.12.14-lp150.12.25.1 bei dem Strg+Alt+F2 bis F6 nur einen schwarzen Bildschirm produziert.
        Andere bekommen zusätzlich auch auf der Terminal-Emulation kein root-
        Login mehr
        (Irgendwo entschuldigt sich am 11.11. jemand dafür, daß dieser Kernel "...aus Zufall..." ungetestest ins Upgrade geschoben wurde)

        Es betraf immer einen Rechner mit einer 08/15-Hardware, einer 08/15-Installation, und der Besitzer hat nicht mehr und nicht weniger gemacht als beim Angebot der Updates gesagt - Installiere sie mir.

0
Von Jürgen Sauer am Fr, 23. November 2018 um 16:49 #

Moin,
Ab Kernel 4.13 ist BTRFS die Wahl.
Standard Setup ist hier 2 Partionen 1 btrfs + 1 swap
Im Moment hier mit Arch + Kernel 4.19-1 auf 20+ Desktops + 3 Servern (Cluster).

BTRFS hat sich den schlechten Ruf vor Kernel 4.13 klar zurecht verdient.
Das wird Jahre dauern, bis das ausheilt. Aber das gilt ja auch für XFS (mit anderen Kernel Schwellen).

Am liebsten wäre mir ein ZFS im Standard Kernel, aber da spielen die Lizenzen nicht mit, es ist immer ziemlicher externer Aufwand ein ZFS zu installieren/betreiben/warten über upgrades hinweg.
Aber solange das nicht geht, ist BTRFS meine "best in praxis" Wahl.

Wir verwenden hier so ziemlich alle Features von BTRFS. (compression, subvolume, snapschot, snapshot based backup, scrub, balance, multi device, raid[0,1,5,6,10], recovery, repair).

  • 0
    Von Holger_W. am Fr, 23. November 2018 um 19:51 #

    Hallo,

    was zfs betrifft: Es kommt auf das OS an, ich habe zfs auf meinem Laptop, auf dem PC meiner Frau und meinem PC und auf unseren Datenserver in Betrieb.

    Auf allen Rechnern läuft allerdings kein GNU/Linux, sondern ein FreeBSD 11.2-RELEASE.

1
Von ExtendedZero am Fr, 23. November 2018 um 17:12 #

Ganz langweilig, ext4 auf dem root FS, und alle anderen "Partitionen" immer mit XFS, d.h. /home, /usw, /nocheinverzeichnisname etc.

Mit XFS habe ich gute Erfahrungen seit 10 Jahren, und ext4 weil ich schon immer ext im / benutzt habe. Angefangen hat das mit ext2, ext3 habe ich übersprungen, es ist nie zum Einsatz gekommen.

Dann irgendwann angefangen ext4 einzusetzten.

mfg
ExtendedZero

  • 1
    Von Jürgen Sauer am Fr, 23. November 2018 um 17:49 #

    XFS war mal meine Wahl. (Alter SGI/Irix Man, XFS war hausmarke in 1991).

    Liest sich wie unsere Geschichte hier, XFS/Linux war vor 10 Jahren stabil, hatte klasse tools, war aber "lahm". Gut für bestimmte Kunden Server, die es mit der Spannungsversorgung am Server nicht so genau genommen haben...

    Unsere Linux Reise ging hier ext2 -> XFS -> ext4 -> [BTRFS | ZFS | ocfs2] je Anwendung.
    BTRFS wurde nach gründlicher Einarbeitung, Evalulierung [und ein paar total verlusten bei Multi-Volume-Raid5] hier zum Standard.

    ZFS ist aufwendig, muß man immer extra pflegen, BTRFS ist immer an Bord.

    Allerdings sollte man BTRFS nicht bei alten Kernel einsetzen. Unter 4.13 ist BTRFS ein klares "besser nicht".

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Nov 2018 um 17:57.
    • 2
      Von Kris am Fr, 23. November 2018 um 22:39 #

      Ich habe von BTRFS ja auch immer nur gelesen, wenn es schlechte News dazu gab. Würdet Ihr sagen BTRFS ist so langsam 'production-ready'?

      • 0
        Von blubb am Sa, 24. November 2018 um 11:50 #

        Solange man um raid5/6 einen Bogen macht sollte es ok sein.
        bzgl. raid5/6 hat sich dieses Jahr endlich mal wirklich was getan, allerdings gilt das immer noch als sehr experimentell.

        • 0
          Von Jürgen Sauer am So, 25. November 2018 um 16:16 #

          Selbst Raid5/6 ist aktuellen Kerneln (wie ich geschrieben habe, ab 4.13) stabil einsetzbar.

          Für BTRFS (und andere) Dateisysteme gilt immer noch die Grundregel, beim Einhängen nicht unterbrechen!

          Stecker ziehen - oder Reset - beim Mounten des fetten Multi Volume Raids kann ziemlichen Ärger geben! Manchmal reparierbar, manchmal nicht.
          Lässt man das System lange genug in Ruhe seine bits sortieren ist beim Recovery Run nach einem Stromausfall i.d.R. alles wieder gut.
          Hat der Level User nicht die Einsicht das ein großes Raid nach einem Spannungs Ausfall mal 5 Minuten zum mounten braucht und hektisch Reset drückt, dann kann er sich auf ein desaster recovery einrichten. Dann wird es hektisch ...

          So schafft man auch ein ZFS (und die meisten anderen Filsysteme) platt zumachen ...

2
Von Töppke am Sa, 24. November 2018 um 15:05 #

Nutze ext4. Ich hatte bisher nie Probleme, da ich sowiso nur ein Linux-(be)nutzer ohne Spezialanwendungen bin.

  • 1
    Von Potz Blitz am Sa, 24. November 2018 um 18:10 #

    Ich auch. Nicht bewusst; ich nehme meist was die Distri (derzeit Manjaro) so vorschlägt. BtrFs kann mehr als ext4, wenn man es denn braucht. ZFS ist für (leistungsstarke) Server und XFS scheint Red Hats neuer Favorit zu sein.

    ext4 ist wie mein altes, aber zuverlässiges Auto. Es fährt noch, also warum sich ein neues kaufen?

1
Von Züpfelklatscher am Sa, 24. November 2018 um 19:08 #

Nach für mich persönlich durchgängig nur schlechten Erfahrungen mit Btrfs (Verschlüsslung, Performance) bin ich wieder zu dem zurück was sich in den letzten 10, 12 Jahren bewährt hat: ext4 für /boot, Rest mit verschlüsselten LVM auf xfs.

  • 1
    Von pb2015 am So, 25. November 2018 um 11:14 #

    ja, hier reihe ich mich ein. Nach ziemlich miesen Erfahrungen mit btrfs, wenn verschiedene Kernelversionen oder andere kleine Kleinigkeiten (andere btrfs-tools-Version) auftreten, die schnell zu totalem Datenverlust geführt hätten (wäre kein doppeltes Backup vorhanden gewesen.
    Die Ideen hinter btrfs finde ich weiterhin gut, schlichtweg der Einsatz ist mir zu heikel, insbesondere mit Debian Stretch oder ubuntu.

    1
    Von Klotz am Bein am So, 25. November 2018 um 12:05 #

    Dank BTRFS konnte ich zum ersten (und bisher einzigen) mal erleben wie das tut, wenn sich ein Filesystem praktisch schlagartig von selbst zerlegt.
    Das war ungefähr zu der Zeit, als Edward Shiskin im Auftrag von Red Hat zu der Erkenntnis kam: "...BTRFS is not reliable...".
    Seit dem mache ich einen riesigen Bogen um dieses Konstrukt, so bestechend das Konzept an sich auch sein mag.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten