Dateisysteme - Allgemeine Diskussion

[Asseon]

Das ist jetzt leicht off topic, aber das btrfs raid 5 und 6 nicht Produktionsreif sind weißt du?

 

[sia]

Re: Monit – Btrfs-Dateisystem überprüfen

@phre4k: Ich hätte meine Lösung […] nicht ins Monitoring-System gepackt, sondern nen Cronjob erstellt

Was hätte das für einen Sinn, wenn ich es doch überwachen will? Also was würde der Cronjob in deinem Falle tun?

Theoretisch könnte ich auch ganz Monit durch Cronjobs ersetzen, aber so ist es komfortabler. Oder habe ich da was falsch verstanden?

Das ist jetzt leicht off topic, aber das btrfs raid 5 und 6 nicht Produktionsreif sind weißt du?

Ich kenne die Probleme beim Einsatz in Produktivumgebungen:

From 3.19, the recovery and rebuild code was integrated. The one missing piece, from a reliability point of view, is that it is still vulnerable to the parity RAID "write hole", where a partial write as a result of a power failure will result in inconsistent parity data.

Parity may be inconsistent after a crash (the "write hole")
Parity data is not checksummed
No support for discard? (possibly -- needs confirmation with cmason)
The algorithm uses as many devices as are available: No support for a fixed-width stripe (see note, below)

The first two of these problems mean that the parity RAID code is not suitable for any system which might encounter unplanned shutdowns (power failure, kernel lock-up), and it should not be considered production-ready.

Bei regelmäßigen Backups und redundanter unterbrechungsfreier Stromversorgung ist das keine große Sache.

 

[keinbenutzername]

Re: Monit – Btrfs-Dateisystem überprüfen

kommt natürlich darauf an wo man es einsetzt.
Ich nutze btrfs auch privat ohne schlechtes Gefühl für meine Daten.
Wenn allerdings high availability gefordert ist hört sich das für mich nicht passend an.

Wie stellt sich das Problem denn in der Praxis dar?
Bei nem beschriebenen Problem (Stromausfall, Kernel-Absturz) ist die gerade geschriebene Datei futsch?
Also sowohl die Parität als auch das Original?

 

[sia]

Re: Monit – Btrfs-Dateisystem überprüfen

Na ja, bis auf RAID-5/6 ist ja alles bei Btrfs seit Kernel 4.1 (iirc) stabil. Der ist ja sogar LTS, dürfte also bald bei ziemlich allen Distributionen zum Einsatz kommen.

Das Dateisystem sollte man sowieso dem Einsatzzweck entsprechend wählen. Wenn man Btrfs' Funktionen nicht benötigt, kann man auch xfs oder ext4 benutzen. Letzteres ist ja meistens auch schneller.

Wäre nett, wenn ein Mod die Diskussion zu Dateisystemen ausgliedern könnte, finde das nämlich ganz interessant, passt aber nicht zum Threadthema!

 

[keinbenutzername]

Auch wenn ich es nicht wirklich verstanden habe, aber scheinbar tritt das Problem ja nur auf bei BTRFS raids.
Bei z.B. Synology Boxen wird ein md raid erstellt und darauf dann das BTRFS Dateisystem. Das soll kein Problem sein.

 

[mathmos]

Facebook setzt übrigens Btrfs produktiv ein.

https://www.linux.com/news/learn/in...ok-uses-linux-and-btrfs-interview-chris-mason

Unter SLES (und wenn ich mich nicht täusche OpenSuse) ist Btrfs auch das Standarddateisystem.

---

Privat setze ich auf mehreren Rechnern inzwischen Btrfs ein (zum Teil im Mischbetrieb, zum Teil ausschließlich). Lediglich mein Raspberry Pi nutzt noch Ext4. Funktioniert und Sachen wie die Snapshots sind echt nützlich.

 

[sia]

Na ja, Facebook wird wohl kein Btrfs-RAID5/6 nutzen, oder?

LVM-RAID5 und Btrfs erscheint mir für solche Firmen sinnvoller. Und warum nutzen die überhaupt Btrfs, wenn ext4 beim reinen Datentransfer schneller ist? Der Großteil der Systeme wird doch wohl Storage sein, oder?

Das Interview liest sich eher so, dass Btrfs auf Servern eingesetzt werden, die mit Storage weniger zu tun haben, weil sie Snapshots nutzen wollen.

Hat jemand eigentlich schon ext4-Verschlüsselung ausprobiert? Fand das für Mobilgeräte immer sinnvoll, aber als ich das das letzte Mal versucht hatte, war's ein Beta-Feature und unausgereift.

 

[mathmos]

@phre4k:

Wie Facebook Btrfs nutzt, kann ich nicht sagen. Nur halten viele halt Btrfs auch abseits von Raid5/6 für gefährlich. Und da es sich hier ja um einen allgemeinen Diskussionsthread handelt, wollte ich eben mal darauf hinweisen.

Im Interview wird angegeben dass einige Cluster zur Datenspeicherung mit Btrfs laufen. Als Grund wird CRC (cyclic redundancy checks) der Daten und Metadaten angegeben. Schnelligkeit des Dateisystems scheint hier wohl nicht ganz so wichtig zu sein.

 

[sia]

Was mich ein bisschen genervt hat ist, dass die aktuelle Debian-Installer-Version immer noch einen 3.16er-Kernel hat und somit nicht von Btrfs booten kann.

Die meisten anderen Dateisysteme funktionieren.

Wäre für einen Raspi nicht F2FS eine gute Idee? Ich habe zumindest einige Raspis (>100) mit F2FS laufen und bisher keine Probleme, dafür aber weniger ausfallende SD-Karten.

 

[mathmos]

@phre4k:

F2F2 hatte ich erst auf dem Schirm, nachdem ich den Raspberry komplett eingerichtet habe. Seit 2015 läuft der Raspberry daher mit ext4 (frei nach dem Motto "Never change a running system"). Ein Wechsel der SD-Karte wegen einem Defekt war noch nicht nötig. Von daher sehe ich das eher gelassen. Muss dazu aber auch sagen, dass ich zum Beispiel das Schreiben von Log-Dateien (z. B. durch den Q3A-Server der bis vor Kurzem noch darauf 24/7 lief) stark eingeschränkt bzw. deaktiviert habe und auch keine billige SD-Karten nutze.

 

[sia]

So, ihr Banausen, hatte ein System mit Btrfs RAID5, bei dem die letzten paar Wochen sicher ein Dutzend Mal der Strom gekappt wurde.

scrub status for f9b14dad-908b-44d0-b184-5ad139746fcd
	scrub started at Sun Jan 22 00:04:16 2017 and finished after 77:24:20
	total bytes scrubbed: 7.80TiB with 0 errors

Write hole ist mir jetzt auch nicht aufgefallen, habe aber auch nicht alle Daten manuell durchgeschaut. Backup der wichtigen 3TB liegt auf nem Btrfs RAID1 in einem anderen System.

Klar, ist nur ein Rechner von Millionen, aber ich hatte mit sicher zwei Dutzend physischen und 150-200 virtuellen Maschinen mit Btrfs keinerlei Probleme.

 

[keinbenutzername]

kannst du dich noch erinnern wie du das aufgesetzt hast?
Also per
mkfs.btrfs -f -d raid5 -m raid5 -L oder so ähnlich denke ich?

 

[sia]

Ungefähr so, ja – zumindest sagt mir das btrfs fi df.

Ich meine aber, ich hätte die Devices nicht alle auf einmal angegeben sondern nacheinander hinzugefügt. Ist aber auch schon ne Weile her, da müsste ich in die Logs schauen

 

[mathmos]

Scheinbar gab es Ende des Jahres auch einen Bugfix, der Raid5/6 merklich stabiler gemacht hat. Alle Bugs sind aber scheinbar noch nicht behoben.

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

 

[sia]

@mathmos: Auf dem System läuft allerdings noch Kernel 4.1 LTS, da wäre der Fix ja dann noch nicht drin, oder? Oder zählt das als backport-enswerter Bugfix?

Habe mich da ehrlich gesagt noch gar nicht eingelesen, obwohl's vielleicht mal nötig wäre.

 

[mathmos]

Keine Ahnung ob das für einen Backport reicht. Wird vermutlich sowieso von Distribution zu Distribution anders gehandhabt. Habe aber gerade gemerkt, dass der Patch erst für 4.10 vorgesehen ist. Soweit bin ich selbst unter Arch noch nicht. Dachte der Patch hat schon Einzug gehalten.

Allerdings gibt es in oben genannter Mailing List auch noch einen anderen, nur ein paar Tage alten Thread zum Status von Raid5/6 in Verbindung mit Btrfs. Liest sich jetzt nicht sehr positiv.

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

Bin immer wieder froh, dass ich selbst auf Raid jeder Art verzichten kann.

 

[sia]

Bin immer wieder froh, dass ich selbst auf Raid jeder Art verzichten kann.

Wie meinst du das? Was machst du, wenn Festplatten ausfallen, in der Zeit, bis die Backups zurück gespielt sind?

EDIT: Ah, in der Mailingliste wurde ne nette Statusseite verlinkt:
https://btrfs.wiki.kernel.org/index.php/Status

Übersieht man leicht auf der Startseite, die ist doch sehr textlastig.