[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problem mit btrfs



Am Donnerstag, 14. Juli 2016, 12:47:24 CEST schrieb Sven Hartge:
> Martin Steigerwald <martin@lichtvoll.de> wrote
> 
> > Meine Empfehulung für BTRFS mit Debian Jessie: Den jeweils aktuellen
> > Backport- Kernel verwenden. 3.16 ist in Bezug auf BTRFS schon sehr
> > alt. Wie gut die Debian Kernel Maintainer kritische Fixes für BTRFS
> > auf den 3.16er-Kernel rückportieren, habe ich bislang nicht geprüft.
> > Da ich da auch keinen Anlaß für sah. Ich nutze einfach immer den
> > aktuellen Backport-Kernel.
> 
> Auf Debian-Devel gibt es aktuell hier eine interessante Diskussion.

Ah, okay. Das wusste ich nicht. Danke. Ich hab mich damals im Zuge der 
systemd-Diskussion aus debian-devel ausgetragen. Ist das irgendwo in dem 
Monster-Thread: "Installer of Debian Stable allows to use btrfs for /, does it 
mean it's mature enough to use safely?"? – bevor ich da weitere Zeit 
investiere, durch den Thread zu klicken, um die Diskussion, die Du meinst, zu 
finden.

https://lists.debian.org/debian-devel/2016/07/threads.html

Das kann natürlich auch mal passieren. Vielleicht ist dann auch sinnvoll, mit 
der Aktualisierung auf den letzten Backport-Kernel ein paar Wochen zu warten, 
was ich üblicherweise aber auch mache.

Auf der Upstream-Mailingliste ist mir nichts sonderlich aufgefallen, es gibt 
jedoch:

http://www.spinics.net/lists/linux-btrfs/msg55985.html

Fix bereits in 4.6.1:

http://www.spinics.net/lists/linux-btrfs/msg55986.html

Ansonsten scheint es auf der Upstream-Mailingliste bezüglich 4.6er-Kernel sehr 
ruhig zu sein.

> Fakt ist, dass Kernel 4.6.0 für btrfs unbedingt gemieden werden sollte,
> weil es einen noch nicht behobenen Datenkorruptions-Bug gibt. 4.5.0 ist
> dagegen stabiler.

Das glaube ich erstmal so nicht, weil ich die entsprechende Diskussion noch 
nicht gefunden habe. Und auch auf der Upstream-Mailingliste keine 
entsprechenden Hinweise gesehen habe.

Zudem gibt es doch mittlerweile mehrere Bugfix-Releases. Ist ja mittlerweile 
Upstream bei 4.6.4. Auch ich habe hier mindestens 4 Systemen keine Probleme 
gehabt. Alle außer meinem Haupt-Laptop, das mittlerweile mit 4.7-rc5 läuft, 
laufen derzeit noch mit 4.6er-Backport-Kernel.

Kann echt sein, dass Deine Aussage stimmt, hab aber die exakte Fundstelle, 
Deinen Beweis auch beim überblicksartigen Durchklicken durch oben genannten 
Thread nicht gefunden. Eine Einzel-Aussage ist zudem nur beschränkt 
glaubwürdig.

> 3.16 ist auch eine stabile Option für btrfs.

Minus möglicherweise Kernel-Hängern BTRFS-Dateisystem, auf dem auf dem Gerät 
alle Chunks belegt sind. Da ist erst mit 4.4 oder 4.5 auf meinem Laptop 
verschwunden. Und ob dieser Fix mal rückportiert wurde?

Minus wer weiß was sonst für Fixes, die die Debian-Maintainer möglicherweise 
nicht in den 3.16er-Kernel rückportiert haben.

Wobei allerdings

https://tracker.debian.org/media/packages/l/linux/changelog-3.16.7-ckt25-2

eine ganze Reihe von Fehlerbehebungen auflistet.

Okay, ich hab das jetzt nicht mit den Upstream-Logs verglichen, aber da sind 
echt einige Fixes. Allerdings wie es für mich auf den ersten Blick aussieht, 
eher isolierte Fixes. Ob, sich damit alle wesentlichen Probleme von BTRFS 
korrigieren ließen… ich weiß es nicht.

So oder so dürfte der typische Kommentar auf der Upstream-BTRFS-Mailingliste 
sein: Teste nochmal mit einem aktuellen Kernel.

> Grundsätzlich sollte man aber bei btrfs die internen RAID-Optionen
> meiden, da dies in jeder Version hoch experimentell sind.

Komisch. Das nutze ich seit über 2 Jahren produktiv – und hochexperimentell 
deckt sich meines Wissens auch nicht mit der Einschätzung der Upstream-
Entwickler:

http://blog.teamix.de/2014/04/22/ssd-raid-1-mit-btrfs/

http://blog.teamix.de/2015/01/19/btrfs-raid-1-selbstheilung-in-aktion/

http://www.heise.de/open/meldung/Btrfs-Erfinder-stuft-sein-Linux-Dateisystem-als-stabil-ein-2437356.html

Und das funktioniert auch.  RAID 1 allerdings.

Und ich hab zusätzlich auch andere in SLES ausgeschaltete Features aktiv, wie 
autodefrag (auf Festplatten) und compress=lzo.

RAID 5+6 würde ich noch nicht für Daten einsetzen, die mir wichtig sind. Da 
gibt es auf der BTRFS-Upstream-Mailingliste mehr als einen Thread dazu, dass 
diese kaputtgegangen sind. Nicht jedoch mit RAID 0, 1 oder 10.

Ciao,
-- 
Martin


Reply to: