# btrfs auf Produktivsystem

## tazinblack

Hallo zusammen,

ich will mir die Tage ein neues System aufsetzen und frage mich welches FS ich nehmen soll.

Auf meinem Notebook habe ich schon seit 9 Monaten btrfs auf ner SSD und bin zufrieden.

Allerdings nutze ich dort auch keine besonderen Features.

Inzwischen soll ja das "disk format" stable sein.

Die neue Kiste soll Mail- und Webserver werden. Zwar nur für den privaten Gebrauch, aber wer 

verliert schon gerne seine Mails, etc.

Interessant finde ich generell Snapshots und Kompression mit lzo, Deduplizierung.

Z.B. könnte ich mir vorstellen, den Bereich in dem Mails liegen zu komprimieren.

Grundsätzlich würde ich trennen wollen zwischen System und Nutzdaten.

Also z.B. nach fehlerhaften Systemupdates wieder auf den Snapshot vorher zurück zu können, ohne dabei 

z.B. in der Zwischenzeit eingegangene Mails zu verlieren.

Leider finde ich die ganze Bedienmechanik doch recht komplex.

Vielleicht liegts auch dran, dass ich damit (noch) nicht so vertraut bin.

Gibts da bei Euch erste Erfahrungen?

Danke im Voraus für die Tipps!

----------

## kernelOfTruth

Btrfs läuft hier auf /usr/portage & / (system root)

der Rest auf ZFS

Infos:

Snapshots, Senden:

http://marc.info/?l=linux-btrfs&m=140974713506816

http://marc.info/?l=linux-btrfs&m=141014110627013

Subvolumes:

http://marc.info/?l=linux-btrfs&m=141038814918997

Datenverlust nach Crash:

http://marc.info/?l=linux-btrfs&m=140872365809680

OOM bei Scrub, normaler Nutzung, etc.:

konnte bis jetzt nur stärkeren RAM-Verbrauch als ZFS feststellen

ENOSPC:

http://marc.info/?l=linux-btrfs&m=141027296608438

Kompression, rsync:

http://marc.info/?l=linux-btrfs&m=140957843615564

Btrfs unterstützt bis jetzt nur gzip & lzo

mit beiden gibt es die genannten timeouts (ohne wohl nicht), gzip komprimiert nicht besonders effizient: damit sind manche Dateien größer also original - mit mit lz4 & ZFS keine vergleichbaren Beobachtungen

lz4 ist momentan keine Priorität für Btrfs

Deduplizierung:

lief unter ZFS recht langsam (auf früherem Rechner), mittlerweile gibt es AVX-Beschleunigung für Prüfsummen als Pull auf github (https://github.com/zfsonlinux/zfs/pull/2351)

damit sollte es mit aktuellen Prozessoren performanter laufen

ich nutze unter ZFS Ditto Blocks:

https://blogs.oracle.com/relling/entry/zfs_copies_and_data_protection

das sind im Endeffekt zusätzliche/separate Volumes unter dem Root vdev und den Subvolumes vergleichbar

Btrfs-Nutzung & Stabilität:

Hier im Forum, Phoronix und anderswo gibt es auch äußerst positive Berichte über Nutzer von Btrfs die z.B. mit tausenden Btrfs Snapshots arbeiten und bis jetzt noch keine Problem damit hatten.

Versuchen schadet nichts - wenn es nicht gehen sollte, gibt es immerhin ZFS mit dem eine vergleichbare Funktionalität gegeben ist

Regelmäßige Backups auf andere Dateisysteme sind Pflicht

----------

## kernelOfTruth

Falls Interesse besteht: 

in meinem Repo auf github ist der neuste Integration-Ast mit einem Fix (https://github.com/kernelOfTruth/linux/commit/793acd97e3f15b283bffa4f448f157d294be756c), der das ENOSPC-Problem beheben soll

https://github.com/kernelOfTruth/linux/commits/btrfs-integration_13.09.2014%2Bfixes

er enthält 8 zusätzliche Patches zu http://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/log/?h=integration

einen darauf basierenden Kernel setze ich zur Zeit hier ein,

damit sollten wirklich die allergröbsten Fehler - auch in Verbindung mit Daten-Korruption beim nicht-sauberen Herunterfahren (Reset, Hardlock, etc.) - hoffentlich behoben sein

----------

## Klaus Meier

Ich nutze schon seit einiger Zeit btrfs und bin begeistert. Zum einen ist es extrem robust bei einem Crash. Habe hier so ein Laptop, welches im Sommer gerne mal wegen Überhitzung einfach abschaltet. Nein, es taktet nicht runter, was man ja machen könnte. Dank cow hatte man dann in einigen Fällen nur die letzte Version einer Datei. Aber die war immer zu 100% in Ordnung. Bei einem anderen FS wäre es schon möglich, dass die Datei einfach defekt ist.

Datenverlust habe ich noch keinen gehabt. Ich lege jeden Tag als erstes einen Snapshot vom System an und dann kann man eigentlich tun und lassen was man will. Es ist ja immer die alte Version einer Datei vorhanden. Ich denke mal, ein Datenverlust durch Fehlbedienung ist deutlich häufiger als durch einen FS-Crash.

Ich kann es nur empfehlen.

----------

## tazinblack

 *kernelOfTruth wrote:*   

> Falls Interesse besteht: 
> 
> in meinem Repo auf github ist der neuste Integration-Ast mit einem Fix (https://github.com/kernelOfTruth/linux/commit/793acd97e3f15b283bffa4f448f157d294be756c), der das ENOSPC-Problem beheben soll
> 
> https://github.com/kernelOfTruth/linux/commits/btrfs-integration_13.09.2014%2Bfixes
> ...

 

Auf meinem Notebook habe ich ja auch schon btrfs. Allerdings mache ich bisher keine Snapshots.

Kannst Du noch was zur Struktur sagen? 

Hast Du Subvols und wenn ja für was? 

Trennst Du zwischen System und Daten?

Was kernelOfTruth oben berichtet hat, klingt doch eher etwas unentspannt.

Manuell nachpatchen wollte ich eigentlich auch nicht.

----------

## kernelOfTruth

 *tazinblack wrote:*   

> 
> 
> Auf meinem Notebook habe ich ja auch schon btrfs. Allerdings mache ich bisher keine Snapshots.
> 
> Kannst Du noch was zur Struktur sagen? 

 

Bezüglich, wie ich das Dateisystem nutze ?

momentan auf 3 "Partitionen"

/ (system; lzo-Kompression - auf SSD)

/ (/usr/portage; lzo-Kompression - auf SSD)

/var/tmp (auf einem 8 GB zram-Laufwerk mit lz4-Kompression - Btrfs selbst läuft ohne Kompression)

 *tazinblack wrote:*   

> 
> 
> Hast Du Subvols und wenn ja für was? 

 

momentan noch nicht, aber wenn ich meinem Bauchgefühl trauen darf könnte ich diese bald für die System-Partition und /usr/portage einsetzen,

besonders Snapshots sind praktisch wenn ich mal wieder das System mit experimentellen/unstable Programmen aus Overlays z.B. Update

da sieht die Stabilität aber noch nicht so toll aus, wenn ich die Berichte in der Mailingliste richtig interpretiere

wie bereits geschrieben - bei manchen gibt es wohl gar keine Probleme - ergo "YMMV"  :Wink: 

 *tazinblack wrote:*   

> 
> 
> Trennst Du zwischen System und Daten? 

 

Auf jedenfall !

Das System, /usr/portage, /var/tmp sind auf separaten (Btrfs) Partitionen, die Daten sind momentan noch ausschließlich auf ZFS

besonders weil ZFS wohl zu langsam auf der Systempartition und auch (relativ) schwierig zu konfigurieren ist [besonders im Single-Drive-Betrieb]

weiters traue ich Btrfs noch nicht vollständig (ENOSPC, Partition voll ohne die aller aktuellsten Patches (http://marc.info/?l=linux-btrfs&m=141178540704904)) - spontane Datenkorruption oder Verlust der Zugriffsmöglichkeit nach Absturz [gibt es aktuell bei ZFSonLinux aber als "Issue" auch]), setze ich es noch nicht in größerem Maße als Backup oder Datenplatte ein

Der aktuelle Stand ("integration" http://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/log/?h=integration + Patches == https://github.com/kernelOfTruth/linux/commits/btrfs-integration_13.09.2014%2Bfixes_18.09.2014_v2)

schaut schon ziemlich gut aus und mit den btrfs-progs 3.16.1 zeigt er sogar die Fehler im syslog bzw. dmesg - welche Dateien defekt sind:

Mal ein Beispiel:

 *Quote:*   

> btrfs scrub status /bak
> 
> scrub status for 8f518282-fea8-4bd1-ade9-20796f142684
> 
> 	scrub started at Fri Sep 26 18:32:09 2014 and was aborted after 1119 seconds
> ...

 

bis vor ein paar Tagen hatte ich mich gewundert, warum er auf dieser gar nicht so alten Platte (2.5 Jahre alt) auf einmal Fehler anzeigt - Ende August war das ganze noch Fehlerfrei,

hatte davor aber schon manuell ca. knapp 10 Sektoren neu schreiben lassen (pending sectors) und extended offline S.M.A.R.T.

zeigte nichts mehr an

 *Quote:*   

> #19  Short offline       Completed: read failure       10%     17128         3058543265
> 
> #20  Short offline       Completed without error       00%     17119         -
> 
> #21  Short offline       Completed: read failure       10%     17118         3058543264
> ...

 

Ich hab deshalb gestern abend mal ZFS drauf gemacht und startete ein zpool scrub - siehe da:

 *Quote:*   

> zpool status 
> 
>   pool: WD20EARS
> 
>  state: ONLINE
> ...

 

es werden immer mehr Fehler und scrub läuft noch - der Platte ist also nicht mehr über den Weg zu trauen   :Rolling Eyes: 

Die Fehlermeldungen und Btrfs' Fähigkeiten scheinen durchaus (noch bzw. wieder) zuverlässig zu sein in Bezug auf Erkennung von defekter Hardware   :Laughing: 

 *tazinblack wrote:*   

> 
> 
> Was kernelOfTruth oben berichtet hat, klingt doch eher etwas unentspannt.
> 
> Manuell nachpatchen wollte ich eigentlich auch nicht.

 

naja - das war es bis vor kurzem auch:

bis vor ein paar Tagen kamen auf einmal dutzende (und mehr) Fehler auf der System-Partition, die zwar erfolgreich behoben werden konnten

beunruhigt war ich dann aber schon

Formatierung und 3-4-fache Tests der SSD unter Windows brachten aber nichts zutage

Darum wieder ein stage4-Backup zurück und jetzt läuft es ohne Meldungen

dennoch merkwürdig - wird wohl durch die vielen aktuellen Patches verursacht worden sein

und es fanden sich höchstwahrscheinlich einige gröbere Probleme (Bugs seit es Btrfs gibt), Mängel bzw. effizientes Platzmanagement, etc. etc., die nun nicht mehr auftreten sollten

frisch formatiert + aktueller Kernel sollte einiges davon behoben sein

Na dann wirst du wohl oder übel bis mindestens 3.18 oder 3.19 warten müssen, dass es besonders in Bezug auf ENOSPC und Datenintegrität nach Abstürzen (Filipe Manana hat hier wirklich beeindruckende Arbeit geleistet) für den täglichen Einsatz geeignet ist - die notwendigen Änderungen sind im "Integration"-Zweig vorhanden, der frühestens in 3.18 drin sein wird

besonders

Btrfs: remove empty block groups automatically

(ENOSPC)

und diverse patches bezüglich 

data corruption, fsync, etc.

werden wohl erst da standardmäßig in Btrfs enthalten sein, ein Teil wird mit Sicherheit zurückportiert

----------

## tazinblack

 *Klaus Meier wrote:*   

> Ich nutze schon seit einiger Zeit btrfs und bin begeistert. Zum einen ist es extrem robust bei einem Crash. Habe hier so ein Laptop, welches im Sommer gerne mal wegen Überhitzung einfach abschaltet. Nein, es taktet nicht runter, was man ja machen könnte. Dank cow hatte man dann in einigen Fällen nur die letzte Version einer Datei. Aber die war immer zu 100% in Ordnung. Bei einem anderen FS wäre es schon möglich, dass die Datei einfach defekt ist.
> 
> Datenverlust habe ich noch keinen gehabt. Ich lege jeden Tag als erstes einen Snapshot vom System an und dann kann man eigentlich tun und lassen was man will. Es ist ja immer die alte Version einer Datei vorhanden. Ich denke mal, ein Datenverlust durch Fehlbedienung ist deutlich häufiger als durch einen FS-Crash.
> 
> Ich kann es nur empfehlen.

 

Kannst Du noch was zu der verwendeten Struktur/Subvols sagen?

----------

## Klaus Meier

Ich habe eine Partition, auf der mein System ist. Komplett. Und dann noch ein eine andere, auf der ich etwas zum Spielen habe. Oder als Rettungssystem, wenn das erste nicht mehr will. Ok, ist nicht optimal, aber mein Rechner hat gerade die Grätsche gemacht und ich bin hier erst mal an einem Notsystem. Eine perfekte Lösung ist in Arbeit...

Ich benutze ansonsten nur Snapshots. Mache ich jeden Morgen als erstes, wenn ich die Kiste einschalte. Das ist alles. Kannst du dich mit deinem System austoben und tun und lassen, was du willst. Passiert ja oft mal, dass man aus Versehen etwas löscht oder kaputt editiert. Dann holst du dir die alte Version aus dem Snapshot wieder. Und wenn du dir dein ganzes System geschrottet hast, dann boote ich das andere System, lösche alles bis auf /home und kopiere mir das lauffähige System aus dem Snapshot wieder zurück.

Bin jetzt seit Februar 2013 auf Btrfs. Und wenn es demnächst noch besser wird, dann sage ich nicht nein.

----------

## tazinblack

[quote="kernelOfTruth"] *tazinblack wrote:*   

> 
> 
> Auf meinem Notebook habe ich ja auch schon btrfs. Allerdings mache ich bisher keine Snapshots.
> 
> ...

 

Wenn ich auch bisher nur gute Erfahrungen damit gemacht hab, habe ich ich jetzt vorerst mal doch noch für ext4 entschieden. Btrfs ist mir momentan doch noch nicht stable genug.

So hab ich dann immer noch die Möglichkeit das Ganze nach btrfs zu konvertieren.

Danke für die Tipps!

----------

## Klaus Meier

Na prima, das ist jetzt so etwas wie der Gau. So wie es aussieht, gehen seit Kernel 3.17 keine Snapshots mehr. Man kann sie anlegen, aber dann nicht mehr drauf zurückgreifen und sie auch nicht mehr löschen. Die Daten sind aber weiterhin in Ordnung.

----------

## franzf

 *Klaus Meier wrote:*   

> Na prima, das ist jetzt so etwas wie der Gau. So wie es aussieht, gehen seit Kernel 3.17 keine Snapshots mehr. Man kann sie anlegen, aber dann nicht mehr drauf zurückgreifen und sie auch nicht mehr löschen. Die Daten sind aber weiterhin in Ordnung.

 

Ich denke das ist kein Feature sondern ein Bug...

Ich hatte in der Vergangenheit auch den ein oder anderen Schreckensmoment und hab mir angewöhnt bis mindestens 3.xx.3 zu warten. Da sollten die gröbsten Schnitzer ausgebügelt sein.

----------

## kernelOfTruth

 *franzf wrote:*   

>  *Klaus Meier wrote:*   Na prima, das ist jetzt so etwas wie der Gau. So wie es aussieht, gehen seit Kernel 3.17 keine Snapshots mehr. Man kann sie anlegen, aber dann nicht mehr drauf zurückgreifen und sie auch nicht mehr löschen. Die Daten sind aber weiterhin in Ordnung. 
> 
> Ich denke das ist kein Feature sondern ein Bug...
> 
> Ich hatte in der Vergangenheit auch den ein oder anderen Schreckensmoment und hab mir angewöhnt bis mindestens 3.xx.3 zu warten. Da sollten die gröbsten Schnitzer ausgebügelt sein.

 

mindestens !   :Laughing: 

Wenn ich mir die aktuellen Geschichten mit Reiserfs, RCU stalls, etc. mit 3.17 anschaue dauert es wirklich mindestens so lange, bis die wichtigsten Funktionen getestet und die gröbsten Schnitzer raus sind

Mehr Tester braucht der Kernel   :Wink: 

Ein Heads-Up:

zur Zeit gibt es wohl Dateisystem-Korruption mit Snapshots und 3.17.x

http://marc.info/?l=linux-btrfs&m=141323979805134

----------

## schmidicom

Sorry für die Nekromantie bei diesem Thema (falls das unerwünscht ist) aber wie sieht es eurer Meinung nach bei btrfs heutzutage aus?

Ich spiele seit einiger zeit mit dem Gedanken btrfs eine weitere Chance zu geben.

Grund dafür ist unter anderem halt das es bei XFS, trotz seiner hohen Stabilität (ist mir noch nie gecrasht), einige Dinge gibt die einem auf den Zeiger gehen können. Zum Beispiel sind die dazugehörenden Userspace-Tools halt alles andere als "schön gemacht", sie sind sogar so speziell das SYSTEMD-FSCK@.SERVICE( :Cool:  jedes mal beim Versuch eine Dateisystemprüfung durchzuführen kläglich scheitert. Und auch die schon seit gefühlt einer Ewigkeit angekündigten Features wie Snapshots und ein standardmäßig aktiviertes CopyOnWrite lassen ziemlich lange auf sich warten.

----------

## mike155

Ich würde ja gerne etwas zu Btrfs schreiben - aber da ich nur ext4 verwende, kann ich nicht mitreden.

Warum ich nur ext4 verwende? Für mich zählt bei Dateisystemen nur eines: dass sie meine Daten nicht zerstören. ext4 verwende ich seit über 10 Jahren. Auf einer ganzen Reihe von Systemen. Ich hatte noch NIE Probleme mit ext4 und ich habe noch NIE Daten durch ext4 verloren.

Warum sollte ich also jemals wieder etwas anderes wollen als ext4?

----------

