Warnung vor btrfs
Mal ein Hinweis zum Thema Linux.
Die angestammten Dateisysteme unter Linux (namentlich ext2, ext3, und ext4 ; früher war ich mal eine Zeit Fan von reiserfs, aber das hat sich ja auch erledigt und auch technisch so manche Tücke) sind robust, aber veraltet.
Frischen Wind versprach btrfs, das ein paar Eigenschaften hat, die für manche Dinge echt toll sind. Bessere Speicherverwaltung, eingebaute Kompression, eingebautes RAID (das im Gegensatz zu mdadm-RAID nicht den bevorzugt, der zuerst antwortet, sondern mit Prüfsummen die Quelle auswählt, bei der die Prüfsumme stimmt), Subvolumes, und was mir am wichtigsten ist: Snapshots auf Volume-Ebene.
Zwar ist btrfs immer noch als „experimentell” gekennzeichnet, aber da es verschiedene Linux-Distributionen längst einsetzen, gilt das bislang als brauchbar.
Meinen Erfahrungen nach ist es das aber nicht (hautpsächlich unter Ubuntu 12.04 mit 3.2-Kernel gemacht).
Ich habe btrfs jetzt mehrfach eingesetzt, um Backups auf externe Festplatten zu erzeugen. Dafür wäre es eigentlich genial geeignet, wenn es denn stabil funktionieren würde. Durch die Kompression habe ich Daten draufbekommen, die auf der Quell-Maschine per du deutlich mehr Platz belegen, als die Platte groß ist, und sogar noch viel Luft gehabt. Trotzdem muss man nicht irgendwie rumzippen, sondern sieht die Datein normal im Verzeichnis.
Auch die Sache mit den Snapshots ist da genial. So kann man nämlich mehrere Backups auf eine Platte legen (und ganz einfach mit rsync erzeugen), ohne dieselben Dateien jeweils mehrfach zu schreiben. Man kann einfach mehrere Snapshots machen und hat so den Stand von Januar, Februar, März usw.
Wäre genial.
Aber murks.
In letzter Zeit sind mir immer wieder Abstürze in den Kernel-Logs aufgefallen. Ab und zu wird dann mal ein btrfs unlesbar und muss neu gemounted werden. Die Code-Qualität ist offenbar lausig.
Neulich wollte ich mal (glücklicherweise nur auf einem Testrechner) eine btrfs-Partition vergrößern. Ging nicht. Weil bei Ubuntu 12.04 offiziell kein taugliches Tool dafür dabei ist und sich die aktuellen Sourcen partout nicht compilieren ließen und nicht mehr zum Kernel passten. Pflege offenbar unzuverlässig. Resize geht also nicht.
Und jetzt ist mir das Dateisystem auf der Platte kaputt gegangen, viele Daten nicht mehr lesbar. Und da hängt sich dann das Dateisystem gleich ganz aus, geht auf „unreachable”. Gut, ist nicht so schlimm, weil nur eine Backup-Platte von mehreren, aber halt erstens ärgerlich (weil ich eben die Archivierungsfunktion ganz gern hatte) und zweitens aufschlussreich.
Dann gibt es kein brauchbares fsck. Es gibt zwar formal eins, das taugt aber nichts. Ich hab nämlich jetzt ne Platte mit kaputtem Dateisystem laufen lassen, und das fsck hat nach (!) Auftreten der Fehler noch behauptet, auf der Platte wäre alles bestens. Ich erwarte ja nicht mal primär, dass das Ding alles repariert, aber wenigstens anzeigen sollte es schon können, was kaputt ist.
Wenn ich ein fsck.btrfs aufrufe, bekomme ich nur ne Meldung, ich solle doch btrfs check oder btrfs restore aufrufen. Is ja auch ganz toll, wenn die automatischen Checks nicht funktionieren und das dann so vor sich hindegeneriert.
Zumindest in der Version des 12.04 / 3.2 Kernels ist btrfs nicht stabil brauchbar. Was’n Scheiß, denn die Eigenschaften hätte ich schon dringend brauchen können.
Ich werde mich nun mal zfs zuwenden. Das verspricht noch bessere Eigenschaften, und steht in dem Ruf, robust und zuverlässig zu sein. Ein Nachteil ist, dass Sun/Oracle, die das entwickelt habe, mit ihren Rechten inkompatibel zur GPL sind und das deshalb nicht in den Kernel und standard-Distributionen integriert werden darf, sondern nachträglich reincompiliert werden muss. Ein anderer Nachteil ist, dass es (im Gegensatz zur Solaris-Version) unter Linux die Verschlüsselung nicht gibt. Will man aber die RAID-Funktion von zfs nutzen (und erst das macht das Ding ja richtig zuverlässig) müsste man jede einzelne Platte separat mit cryptsetup verschlüsseln und jedesmal einzeln aufsperren. Das ist auch Mist. Zudem ist auch das Mounten/unmounten von externen Platten etwas anders und daher nicht kompatibel mit den sonstigen Ubuntu-Mount-Automatismen.
Aber ärgerlich ist das schon, dass die da mit btrfs so’n Murks produzieren und das offenbar auch keiner mehr fertigentwickelt. Irgendwo hab ich gelesen, dass ein CodeReview nicht nur von schlechter Code-Qualität spricht, sondern auch davon, dass der implementierte Code nicht den spezifizierten Algorithmen entspricht.
Nachtrag: Das Dateisystem ist so kaputt, dass viele Dateien nicht mehr lesbar sind und sich das ganze Dateisystem beim Versuch es auszulesen verabschietet. btrfs check fällt dazu nicht mehr ein als
# btrfs check /dev/mapper/xxx Checking filesystem on /dev/mapper/xxx UUID: ... checking extents checking free space cache cache and super generation don't match, space cache will be invalidated checking fs roots checking csums checking root refs found 82140986063 bytes used err is 0 total csum bytes: 1261041908 total tree bytes: 2946949120 total fs tree bytes: 1007087616 total extent tree bytes: 331460608 btree space waste bytes: 497759793 file data blocks allocated: 1941265596416 referenced 1987480231936 Btrfs v0.20-rc1
40 Kommentare (RSS-Feed)
Ich stimme Dir größtenteils bei der Kritik zu, insbesondere was die Verschlechterung von Ubuntu angeht.
Nur für Btrfs kann Ubuntu nichts, und sie setzen es ja auch nicht ein, sie haben es nur eben im Kernel mit drin. Btrfs haben die Kernel-Maintainer selbst vermurkst.
Das “reinpopeln” ist recht einfach und geht sauber:
apt-get install python-software-properties add-apt-repository ppa:zfs-native/stable apt-get update apt-get install ubuntu-zfs
Gut, das sieht sauber aus. Schreib mal bitte, wenn der Test irgendwas interessantes in die ein oder andere Richtung ergibt. ZFS unter Linux weckt jedenfalls mein Interesse 🙂
Bin vor einigen Monaten von FreeBSD zurück zu Debian Linux gewechselt, im wesentlichen weil meine neue Hardware zu neu war und damit ein paar Treiber unter FreeBSD gefehlt haben (ja klar, da hätte ich beim Kauf wohl besser aufpassen müssen) für die es aber unter Debian eine Art hack gab damit es da läuft, insbesondere Netzwerktreiber. Hatte eigentlich schon gedanklich beschlossen in ein paar Monaten zurück zu migrieren (sofern eine Recherche ergibt, dass die Treiber nun nicht mehr fehlen) und ZFS war für den Gedanken einer der wichtigeren Gründe.
ZFS ist genial, aber unter FreeBSD nur mit 64-Bit-Rechner und viiieeel RAM stabil (irgendwas um die 2 GB plus 1 GB je TB Festplattenplatz wird empfohlen). Ob die Linux-Implementation da besser ist, weiß ich nicht und warte auf deine Rückmeldungen, Hadmut. 🙂
Also mein bisheriger Eindruck nach einigen Experimenten ist:
Ge- und umgewöhnungsbedürftig, aber mit Vorteilen gesegnet. Macht bisher auch einen stabilen Eindruck, nur eben nicht den, in die Desktops usw. brauchbar eingebunden zu sein.
Was mich nervt, ist, dass ich noch keine elegant-saubere Lösung für die Plattenverschlüsselung mit RAID habe. Und es scheint so zu sein, dass doch einiges an Verschnitt weggeht. Und das man’s halt extra installieren muss.
Aber ansonsten gefällt’s.
> nur mit 64-Bit-Rechner und viiieeel RAM stabil
Ja, von der 32-Bit-Version wird auch unter Linux abgeraten.
Aber was heißt “stabil”? Doch hoffentlich keine Abstürze?
Jein – ich habe auf zwei redundanten Backup-Systemen (64bit & 32bit) Gentoo installiert (installiert ist ja bei diesen Source-Distributionen ja eher ein Euphemismus) die das gesamte Backup-Aufkommen des Firmennetzes auf btrfs-Platten, sowohl single als auch btrfs-Raids, duplizieren – bisher keine grösseren Probleme als bei ext4 und Kernel-Software-Raids auch. Lästig ist, dass man im Falle des Platten-Clonens z. B. die UUID aus diversen Einträgen von btrfs-Platten “zu Fuss” (ok,ok, ich habe dafür ein script geschrieben) ändern muss. Auch sind die Soft-Raids auf btrfs-Basis auf 32 bit-Maschinen eher unbrauchbar, da viel zu langsam, Reorg-Befehle blockieren solche Maschinen dann auf Tage…
Zum Thema ZFS unter Linux: Ich habe das mal mit zfs-fuse probiert, weil ich ein bestimmtes Feature von ZFS (Block Level Deduplication) nutzen wollte. Am Anfang hat es auch ganz gut funktioniert. Im Laufe der Zeit wurde es immer langsamer und der ZFS-Prozess hat sich gerne mal 4-6 GB Ram und über etliche Minuten 300-350% CPU-Usage auf einem Quadcore Prozessor genehmigt. Das hat also auch seine Tücken.
Bist du sicher, dass die Dateisystemprobleme nicht durch Hardwareprobleme wie z.B. Crashes, Speicherfehler oder Probleme mit der Festplatte bzw. dem USB-Gehäuse (wenn vorhanden) verursacht wurden? Btrfs ist zwar noch “experimental” aber ich halte es doch für unwahrscheinlich, dass der btrfs-Code im Kernel so buggy ist, dass er bei normaler Verwendung des Dateisystems ohne äußere Einwirkung so ein völlig kaputtes Dateisystem produziert. Das Fehlen eines funktionierenden fsck-Programms ist natürlich dennoch völlig inakzeptabel.
Ich hatte eigentlich vor, mir nächstes Jahr (eventuell nach dem Release von Ubuntu 14.04 LTS) ein RAID-System mit btrfs anzulegen. Aber jetzt kommen natürlich doch Zweifel, ob das schon hinreichend stabil ist.
@Jakob: 100%ig ausschließen will ich es nicht, aber Lesefehler des darunterliegenden Block-Devices würde ich als Kernel-Meldungen sehen, zumal die Platte vorher mit einem ext3 tadellos funktioniert hat.
Außerdem hatte ich auch schon Abstürze in den Kernel-Logs bei btrfs auf USB-Sticks. Sauber geschrieben ist das noch nicht.
Ich setze ZFS auf mehreren Rechnern ein und bin sehr zufrieden damit. Insbesondere die “Boot Environments” (siehe beadm(1) und [1]) sind für OS-Updates eine nette Sache. Verschlüsselung auf Dateisystemebene ist soweit ich weiß erst möglich mit ZFS v30, welcher von Oracle noch nicht freigegeben wurde. FreeBSD bietet aber auf Block-Device-Ebene geli(8) an. Geli verschlüsselt dann blockweise die Daten unabhängig vom verwendeten Dateisystem. Durch Verwendung externer Bootmedien wie USB-Sticks kann echtes Full-Disk-Encryption angewendet werden. Habe ich seit mehreren Jahren auf etlichen Rechnern im Einsatz, bin hochzufrieden. Fazit: Umstieg auf ZFS kann ich nur empfehlen. Switch OS is IMHO das Beste, was Dir passieren kann.
Das mit der Verschlüsselung von ZFS ist nur halb richtig. Problem von ZFS ist primär, dass die nette und überall beliebte Firma Oracle seit der v28 nichts mehr rausgegeben hat, wie Sun das noch tat. Das unter Solaris verfügbare ZFS macht problemlos verschlüsselte zpools auf – nur kriegt man die nicht für die freien Versionen exportiert. Andersrum kann Solaris-ZFS auch wieder nix mit den geforkten Versionen anfangen, die das auf ganz andere Weise implementiert haben. Man muss sich also vorher entscheiden, welchen Weg man gehen will, und ist dann, außer beim verschlüsselungsfreien v28, daran gebunden.
Ansonsten gibts wenig Grundsätzliches zu bemängeln. AES ist fein, RAIDZ2 funktioniert prima, Kapazitätserweiterung durch Plattentausch ist problemlos, Scrub tut seine Arbeit, mal nicht verfügbare Platten werden nachsynchronisiert statt nen mehrstündigen Resilver einzuleiten, Kompression und Deduplikation ist nach Bedarf und Ressourcen aktivierbar. Wünschenswert wäre aktuell noch das Verkleinern von vdevs durch Rausnehmen von Platten und optional nur filebasiertes Dedup, also Abgleich ganzer Dateien statt einzelner Blöcke, damit die Performance nicht total in den Keller geht.
Das wäre dann auch die Frage, inwieweit man Oracle noch trauen kann, was Verschlüsselungen angeht.
Die btrfs-Entwickler empfehlen einem immer die neuesten Kernel und user-space-tools einzusetzen.
Etwas mehr Infos gibt es hier:
https://btrfs.wiki.kernel.org/index.php/Getting_started
Wie es mit den Backports für den 3.2er Kernel unter Ubuntu aussieht weiß ich nicht. Aber die btrfs-tools sind schon 3 Jahre alt. Das sowas gut ausgeht würde ich nicht erwarten …
Ich hab hier noch zwei alte 512MB-USB-Sticks, gleiches Modell, exakt gleiche Größe.
Packe ich da ein ZFS drauf, dann hab ich da 440 M frei. Packe ich ein BTRFS drauf, habe ich 478 M frei.
Ich betreibe seit rund einem Jahr mein NAS/sekundär-SAN mit FreeBSD und ZFS. Mein pimäres SAN, eine ESXi-VM, ist ein Ubuntu 12.04 mit einer mittlerweile nicht mehr aktuellen Version von ZoL.
Kurzfassung: Alles scheiße geil!
Mich hat vor allem die Sache mit dem ARC, L2ARC, den Snapshots und send/receive gereizt, weniger RAIDZx oder Deduplikation. Schließlich booten meine Büchsen, auch die Windowsbüchsen, direct via iSCSI. Im Ergebnis kann ich die Dinger jetzt behandeln wie VMs und komplette wie differentiell Backups der Platten sind trivial, wie auch offline Virenscans. Geschwindigkeitsmäßig ist das auch ziemlich gut, wenn auch nicht ganz auf dem Niveau einer lokalen SSD. (Logisch, wenn Ethernet dazwischen hängt.)
Ich kann dir den Umstieg nur empfehlen.
Deduplikation frisst RAM wie blöde. Lies dir die umfangreiche Dokumentation von Sun\Oracle vorher durch und mach dir klar, dass die Aktivierung oder Deaktivierung nur neue Schreibzugriffe betrifft. Vermutlich nimmst du dann lieber nur normale Kompression.
Bei zu wenig RAM kann es dir durchaus passieren, dass die Büchse mehr oder weniger komplett abschmiert. Wahrscheinlicher sind aber erst einmal nur Performanceprobleme. Alles was ich dazu bisher aus erster und zweiter Hand weiß sagt, dass man für Stabilitätsprobleme schon massiv zu wenig RAM und hohen IO-Druck braucht.
Was den ARC betrifft brauchst du, um den L2ARC sinnvoll nutzen zu können, genug RAM um einen entsprechend großen L2ARC verwalten zu können. Normalerweise ignoriert der (L2)ARC (und auch das Gegenstück für Schreibzugriffe, eigene SLOG devices) auch große, zusammenhängende Zugriffe. Unter FreeBSD gibt es dazu einen Schalter, der “streaming reads” gleich behandelt wie kleine Zugriffe.
Wenn du das vor allem für Backups nutzen willst, muss dich das Meiste nicht interessieren.
Mein “NAS” (HP MicroServer) hat 8GB ECC-RAM. Derzeit mehrere ext4 in LVM auf Block-RAID.
Ich denke drüber nach, das auf zfs umzustellen.
Was ich nicht verstehe, ist diese sinnlose Zersplitterung der Ressourcen.
Da hat man nun mit ZFS ein Dateisystem, das kaum Wünsche offen läßt, kann es aber aus lizenzrechtlichen Gründen unter Linux nicht verwenden, also versucht man mit BTRFS das Rad ein zweites Mal zu erfinden und muß dann, weil die zweite Erfindung aber keiner so richtig will, extra noch mit ZFS on FUSE eine Lösung entwickeln, die auch nicht optimal ist.
Das ist doch völlig verrückt!
Für mich jedenfalls ist die Zeit der Experimente entgültig vorbei, ich verwende UFS2 und ZFS unter FreeBSD und Schluß.
Aber ich glaube nicht, das BTRFS jemals richtig auf die Beine kommen wird, jedenfalls zumindest so lange nicht, bis Fedora oder eine andere Major-Distro es definitif als Standartdateisystem verwendet.
Ich habe seit etwa 1.5 Jahren BTRFS auf meiner Samsung830 SSD und meiner HDD drauf, unter Ubuntu (allerdings der aktuellsten Version, nicht 12.04), und hatte mal das Problem dass btrfs-fsck geSEGFAULTed ist als das Datensystem nach einem Stromausfall kaputt war 😉 War natürlich super zu debuggen, ich habs dann aber irgendwie über btrfs-zero-log hinbekommen.
Insgesamt finde ich btrfs deutlich langsamer als EXT und habe daher auch auf meinem Notebook wieder alles neuinstalliert, diesmal mit EXT4.
Was bei HDDs mit dem COW-Konzept natürlich auch irgendwie zu erwarten ist.
Bis auf den fsck-Absturz (insgesamt 2x mit Distributionskernel) hatte ich bisher keine harten Probleme, inzwischen nehme ich aber sowieso fast überall meinen eigenen Kernel her, der natürlich einen wesentlich aktuelleren BTRFS-Code hat.
Es scheint schon noch was daran entwickelt zu werden, z.B. bei 3.12 gibts laut Heise Open eine Art offline-Deduplikation. Das heißt natürlcih nicht dass der existierende Code gewartet wird.
Für Backupplatten ist es natürlich irgendwie praktisch, aber da bin ich ehrlichgesagt zu bup übergegangen, und versuche nicht mehr das auf FS-Ebene zu benutzen.
Letztendlich würde ich bei Neu-Formatierungen immer eher auf ext4 setzen. ZFS hat natürlich viele tolle Features, die ich allerdings für meinen Usecase nicht wirklich brauche.
Ich fahre eine rigide KISS-Strategie und die erlaubt Ext4 und NTFS-3G in Verbindung mit Dump und RSync. (FAT32 ist halt einfach zu gammelig.)
Ich seh nicht ein, für irgendwelche Datacenter privat Filesystemcode zu testen und kostenfrei Bugreports zu erstellen. Was dann letztlich produktiv eingesetzt wird, bekommt man ja wie Oracles ZFS eh nie zu Gesicht. Also sollen die mich bitte mit ihrem Alpha-Dreck in Ruhe lassen.
Ubuntu ist eh nur Canonicals Testplattform für die Eroberung des Smartphone- und Tabletmarkts. Die User sind denen scheißegal.
Vor ein paar Jahren hätte ich auch noch gesagt, daß eine “freie Linux-Distribution” für einen privaten MicroServer ein Nobrainer ist, aber inzwischen kenne ich auch Leute, die mit dem Windows Home Server recht glücklich sind. Der hat auch einige interessante Storage-Features und die funktionieren sogar.
Vom erbärmlichen Zustand des linuxbasierten Desktops will ich lieber gar nicht erst anfangen. Das sieht ja jetzt schon übel aus und demnächst beginnt noch der große Krieg der Display-Server. Danach kann man auf das Thema wohl endlich den Deckel draufmachen.
Mit OpenWRT und Android bin ich dafür recht glücklich. Embedded ist ja auch das einzige, wo Linux außerhalb des Enterprise-Bereichs wirklich in der Breite erfolgreich ist. Das wird wohl seinen Grund haben.
“Die Code-Qualität ist offenbar lausig.”
Ich dachte, das wäre unter Linux ohnehin der Default 😉
Ich brauche zwar diese Snapshot- und RAID-features etc. nicht, oder noch nicht, daher hab ich mir die diversen Angebote da noch nicht angeschaut (ext4 ist ok für meine kleinen PCs at home, brauche keine Extravaganzen für meine paar kleinen Datenmengen).
Aber AFAIK bietet doch LVM auch Snapshots und RAID-Features.
Vielleicht ist das ja eine Alternative.
Aber da ich diese fetaures nicht brauche, weiß ich nicht, ob’s
genug von dem bietet, was Du brauchst.
Aber es läuft wohl stabil.
Was Linux-Distris angeht und die Aktualität der selbigen…
…kannst ja mal ARCH ausprobieren. Gefällt mir jedenfalls ganz gut.
Nachdem ich in der letzten zeit damit einige Erfahrung habe, wird wohl irgendwann auch das Ubuntu hier ganz verschwinden. Das existiert nur noch, weil ich eigentlich Systemadministration zum Kotzen finde und ich keine Lust habe, Systeme neu aufzusetzen.
Aber Ubuntu gefile mir früher auch besser als heute… deswegen läuft hier auch noch eine stark veraltete Version…
… ich würde wohl nur noch Arch einsetzen, bei meinem versuch ein aktuelles Debian auf dem neuen Notebook zu installieren (mit grafischem Installer), hat der ganze Scheiß sich aufgehangen.
Das, nachdem die Platte zwecks Randomisierung fast zwei Tage bearbeitet wurde. Vertane Zeit.
Mit dem Arch liess ich da (ohne graf. Installer) dann endlich was installieren.
Also ist der Gang zurück Debian auch nicht überzeugend gewesen.
BSD habe ich noch nicht ausprobiert, wollte ich immer mal.
Aber als Administrations-Allergiker reiß ich mich nicht drum…
…obwohl die Codebasis von BSD ja angeblich so viel besser sein soll…
> Aber AFAIK bietet doch LVM auch Snapshots und RAID-Features.
Jain. Das stimmt so nicht ganz.
Die Snapshots sind keine echten Snapshots, weil LVM das Dateisystem nicht erkennt, sondern erfolgt immer mit ganz LVM-Blockeinheiten, ist also sehr speicherplatzaufwendig.
RAID wird nicht durch LVM, sondern durch das darunterliegende Mapper-Device erzeugt. Und der ist schlechter, denn der erkennt Lesefehler nur, wenn die Platte Lesefehler meldet und das RAID dann eben von der anderen Platte liest. Prüfsummen werden nicht gebildet. Wenn beide Platten unterschiedliche Daten liefern, merkt das RAID das nicht und kann es auch nicht korrigieren. Bei den heuten Plattengrößen ist die Wahrscheinlichkeit aber durchaus gegeben, dass Platten falsche Daten liefern.
Wenn du schon knapp zwei Jahre alte experimentelle Software testest, dann setz doch bitte auch das Artikeldatum auf 2012 😉
Für mehrere Backups empfehle ich rsync mit –link-dest, das funktioniert sehr gut, jedes Backup besteht aus normalen Dateien, die man direkt verwenden kann, unveränderte Dateien belegen Platz nur einfach (eine Umbenennung führt aber schon zu einer neuen Kopie im Backup). Ich benutze das mit ext4, vorher mit ext3, seit inzwischen 5 Jahren.
> Wenn du schon knapp zwei Jahre alte experimentelle Software testest, dann setz doch bitte auch das Artikeldatum auf 2012
Nonsens. Ubuntu 12.04 ist die aktuelle LTS-Version.
Außerdem hat sich der Status von btrfs seitdem nicht geändert, steht immer noch auf „experimental”. Kein Hinweis darauf, warum die aktuelle Kernelversion da signifikant besser sein sollte.
@Hadmut: ZFS unter FreeBSD wirft einen Panic, wenn der Kernel-Adressraum ausgeht. Darum die sehr zwingende Empfehlung, einen 64-Bit-Kernel zu benutzen. Wenn normaler RAM ausgeht, steigt die CPU-Belastung an und bei weniger Aktivität braucht man auch deutlich weniger.
>Nonsens. Ubuntu 12.04 ist die aktuelle LTS-Version.
Das heißt aber nicht, dass alles aktuell ist. Der Kernel ist quasi von 2012 (es gibt keine Backports des btrfs Code) und die btrfs-tools (enthält btrfsck) ist sogar noch von 2010.
http://packages.ubuntu.com/precise/btrfs-tools
https://btrfs.wiki.kernel.org/index.php/FAQ#Are_btrfs_changes_backported_to_stable_kernel_releases.3F
>Außerdem hat sich der Status von btrfs seitdem nicht geändert, steht immer noch auf „experimental”. Kein Hinweis darauf, warum die aktuelle Kernelversion da signifikant besser sein sollte.
Naja, es wird immer noch weiterentwickelt (lässt sich notfalls auf kernel.org nachvollziehen). Und dass es keine Backports gibt habe ich ja schon angesprochen. Ubuntu 12.04 ist halt einfach alt 😉
Bin jahrelanger NILFS-Benutzer, alles wunderbar, kein Thema.
Außerdem hat sich der Status von btrfs seitdem nicht geändert, steht immer noch auf „experimental”. Kein Hinweis darauf, warum die aktuelle Kernelversion da signifikant besser sein sollte.
Nun, an dem Code wird aktiv gearbeitet.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/fs/btrfs
Ich gehe mal ganz stark davon aus, dass 3.2 und 3.12 signifikante Unterschiede in der Code Qualität aufweisen.
Da bin ich ja froh, daß ich btrfs noch nicht “angefaßt” habe, obwohl ich schon öfter mit dem Gedanken spielte, darauf zu migrieren.
Ich mache alles momentan mit md-raids auf denen ein verschlüsseltes ext4 sitzt. Die “Deduplikation” erfolgt dann “händisch” mit hardlinks per fdupes.
Ich weiß, zwar nicht das gelbe vom Ei, aber läuft stabil.
Darf ich als nicht-IT-ler (aber Linux-Fan seit 1994) mal ein paar Noob-Fragen an die offenbar hier versammelten Experten stellen?
* Warum ist ext4 veraltet?
* Wie schlägt sich NTFS qualitativ im Vergleich?
* Welche Betriebssysteme nutzen eigentlich ZFS?
Ich würde nämlich auch gerne das Beste FS einsetzen und bin etwas verwirrt ob der Vielfalt. (Allein die Vielfalt spricht aber wieder für Linux, und nein – Linux auf dem Desktop ist überhaupt nicht tot, davon bin ich überzeugt).
Danke,
Fry
BetrayFS hatte sich für mich Lektüre dieser Email komplett erledigt:
https://lkml.org/lkml/2010/6/18/144
Hat Oracle die gerüchteweise bei SUN existierende “Kernel Hall of Shame” (ein Pranger für derbe Bugs im SOLARIS-Kern) erhalten? Für btrFS sollte da ein Ehrenplatz geschaffen werden.
Uebliche Faustregel waehre “stable” + 1 Jahr, vorher nur fuer risikofreudige Gesellen zu empfehlen. Das eingebaute RAID halte ich ueberigens fuer einen heftigen Architekturfehler, RAID gehoert nicht ins Filesystem, komplett falscher Layer.
@Hadmut:
Der Status “experimental” sagt meiner Meinung nach nur sehr eingeschränkt etwas darüber aus, wie gut der Code wirklich ist.
Siehe auch die offizielle Antwort https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F
Ubuntu hat immerhin bisher noch nicht den Fehler gemacht, btrfs als Default für alles zu nehmen. Das bedeutet allerdings auch, dass sich kaum jemand die Mühe machen wird, wirklich die (zahlreichen) Änderungen auf den LTS-Kernel backzuporten.
Das alles heißt natürlich noch nicht dass der BTRFS-Quellcode absolut gesehen qualitativ gut ist, aber um pauschal zu sagen, dass es schlecht ist (wäre ja möglich) müsste man meiner Meinung nach zumindest die letzte Stabile Kernelversion ausprobieren, am besten noch ohne Distributionsspezifische Patches. Gerade beim btrfsck-Tool tuts meiner Erfahrung nach nur die aktuellste Version.
Aus persönlicher Erfahrung: Nutze Breda seit zwei Jahren. Es gab ein paar Kernel-Oops, da ich zufällig auf einen Bug trat, aber Daten verschwanden mir nie. Hatte nur positive Erfahrungen.
Korrektur: btrfs, nicht Breda. Ich bring mein Telephon noch um…
Es gibt für 12.04 einen Backport des 3.8-Kernels aus Raring. linux-image-generic-lts-raring hieße das Paket, linux-generic-lts-raring für die Headers. Ich habe keinen Überblick, was sich bei btrfs alles getan hat zwischen diesen Versionen, aber ich hatte auch die Erinnerung, dass es immer wieder mal Thema im Kernelrückblick war. Vielleicht hilfts.
Nutze btrfs als Raid 1 seit Kernel 3.2 jetzt 3.5 bisher ohne Probleme und hatte schon Platten an einem billigen SATA Controller welcher bei Belastung die Verbindung zur Platte resettete. Das FS blieb heil oder konnte immer repariert werden.
Einzig die Ausgabe von df -h geht gar nicht, außer man teilt die Angaben durch 2, dann stimmt es wieder. 🙂
Oracle bietet übrigens einen 3.8er Kernel mit BTRFS ausdrücklich für den Produktivbetrieb an: https://blogs.oracle.com/linux/entry/announcing_the_unbreakable_enterprise_kernel
Von reiserfs{3,4} hab ich mich schon verabschiedet, als man noch nach Nina gesucht hat.
Seitdem ext{2,3,4}, aber immer den dicksten Plattencache den ich mir leisten konnte. System manchmal auf Flashkarten im ro-Mode.
Immer zwei Partitionen drauf: vorne swap oder boot, dahinter die lvm-partitionen.
Verschlüsseltes liegt in Containerdateien im Filesystem.
ZFS ist super (in der alten Firma gab es SUN-Server), aber ohne Verschlüsselung m.E. den Aufwand nicht wert. Der (ECC-)RAM-Bedarf ist auch nicht ohne, das Geld will ich privat nicht ausgeben.
Dann lieber datensparsam.
Ein paar Tage hat man noch Zeit die neue Version von Opensuse zu testen, bevor sie herauskommt. Insbesondere das neue btrfs soll man testen, schreibt man hier:
http://www.opensuse-lernen.de/?p=5837
Das mit Plattenverwaltung, Resize, fsck (auch Verschlüsselung in dem Zusammenhang), installierte Programmdaten vom Dateisystem benutzen usw. liegt miener Erfahrung nach aber a Ubuntu 12.04. Das ist so schlecht geworden. Trotzdem würe ich als sicherheitsaffiner Anwender nie was anderes als ext2 unter Linux einsetzen. Löschen, nur möglich ohne Journaling, kann man unter Linux nur einigermaßen unter ext2.
ZFS kommt von Oracle. Haben wir was aus der NSA-Affäre gelernt?
btrfs ist der Linuxversuch auch so etwas wie ZFS auf die Beine zu stellen, aber bisher ist es eben Murks. Das Ubuntu das einsetzt, heißt ja nichts, Ubuntu ist selbst Murks – meine Meinung davon war mal besser, so etwa zwischen 2008 und 2010. Ich will jetzt nicht ins Detail gehen, was ich alles an Ubuntu nicht mag, würde aber zusammenfassend sagen, dass deren Featuritis nicht unbedingt die Qualität des Produktes steigert. Deren Hang ihre eigenen Standards entgegen der Community durchsetzen zu wollen (etwa Mir anstatt Wayland) und dann auchnoch zu meckern, wenn einzelne Firmen lieber den Community-Standard unterstützen anstatt das Ubuntu-Gefrickel ist einfach kindisch und für OSS kontraproduktiv. Dann noch die Geschichte mit der Amazon-Lense … da würde ich wirklich jedem abraten, den Mist einzusetzen, Debian macht weniger Kopfschmerzen. Andererseits muss ich hier ja sicher keinen Informatiker bezüglich der Auswahl seiner Lieblingslinuxdistribution beraten, nur finde ich es aber auch ganz und gar nicht überraschend, wenn irgendwas unter Ubuntu nicht vernünftig läuft, erst Recht nicht wenn es sich um ein Feature handelt, dass von den Entwicklern noch als experimentell bezeichnet wird. Bei Ubuntu läuft meiner Erfahrung nach öfter mal so einiges nicht. Ob ZFS da besser läuft bezweifle ich aber auch (ich habe bisher gar nicht die Möglichkeiten in Betracht gezogen, ZFS irgendwie in ein Ubuntu rein zu popeln). ZFS selbst ist aber ganz nett und hat coole Features und gerade auch die Snapshots sind für Backups interessant, ich habe sie aber vor allem gerne genutzt, wenn ich am System selbst mal ein paar experimentellere Dinge ausprobieren wollte. Probiert habe ich ZFS aber bisher nur mit einem FreeBSD, was nebenbei bemerkt auch ein ziemlich nettes System ist, nur die Installation und Konfiguration am Anfang dauert ein klein wenig länger als man das von Linux kennt (mal abgesehen von einer Gentoo Stage 1 Installation oder ähnlichem).