BTRFS - schon mutige Unterwegs aufm Produktivsystem ? Frage z. partition. bei 2 HDDs

[Stanger]

Hallo,
wollte mal in die Runde fragen wer von euch schon das BRTFS-Filesystem auf einem Produktivsystem einsetzt und auf welcher Distribution.

Was sind euere Erfahrungen damit ? Gabs Datenverluste ?
Platzprobleme auf Grund der ständigen Snap-shots ?

Bin gerade dabei etwas im Netz zu lesen und da in Kürze ein Umzug meiner Privat-Daten auf ein Linux-PC ansteht suche ich gerade Infos bzgl. Partitionierung (Mint Linux) bei 2 HDD/SSDs (SSD 128 GB fürs OS und 4 TB HDD für Daten sprich "/home" müsste ok sein, oder ? ) und dann bzgl. der Wahl des Filesystems.

mfg
Stanger

[lumines]

OpenSUSE benutzt es soweit ich weiß.

Für mich persönlich werde ich wahrscheinlich noch sehr lange mit ext4 fahren. Bei Dateisystemen mag ich lieber alt und langweilig. Eigentlich bin ich mit ext4 auch nicht unzufrieden. Die Performance stimmt für mich und der sehr schnelle fsck-check beim Booten ist sehr angenehm. Damals bei ext3 haben mich diese langen Checks immer enorm genervt, aber das war eigentlich auch das Einzige, was mich daran gestört hat. Seit ext4 hatte ich eigentlich daher auch kein Bedürfnis mehr für ein anderes Dateisystem.

Partitionierung (Mint Linux) bei 2 HDD/SSDs (SSD 128 GB fürs OS und 4 TB HDD für Daten sprich "/home" müsste ok sein, oder ? )

Ich kam für das OS teilweise sogar mit 20 GB aus. Macht bei heutigen Größen allerdings natürlich wenig Sinn das so klein zu dimensionieren.

Die SSD für das OS und die HDD für /home hört sich auf jeden Fall nicht verkehrt an. Mir fällt da eigentlich auch keine bessere Lösung ein.

[iuno]

Ich benutze seit geschaetzt 1,5 Jahren mit meinem Arch System btrfs sowohl auf SSD als auch auf der Festplatte. Warum? Warum nicht? ;D
Daten werden staendig gesichert, also gab es nichts zu verlieren und ich wollte es eben mal ausprobieren. Das habe ich gemacht und hatte bis jetzt keine Probleme.

Ich mache es genau wie du vor hast, die HDD fuer /home und fuer den Rest die SSD. 120 GiB sind dabei fast schon ueberdimensioniert, aber was solls. Man koennte die SSD nach Belieben ja noch zweiteilen und den zweiten Teil davon irgendwo unter /home Mounten, sozusagen als schneller "cache" oder so...

Es befindet sich uebrigens ein Windows-Treiber fuer btrfs in Entwicklung (https://github.com/maharmstone/btrfs), der auch schon "funktioniert", wenn man etwa von der transparenten Komprimierung oder RAID absieht. Falls man Dual-Boot benoetigt, ist das sicher interessant.

[Abnaxos]

Ich habe mal mit openSUSE Tumbleweed einen Versuch gestartet. Das war – gelinde gesagt – abenteuerlich. Ständig hatte ich Kernel-Oopses im Log (dem Stacktrace nach aus btrfs heraus), gefolgt von einem Remount read-only. Nach wenigen Tagen war es dann soweit: Die Kiste wollte nicht mehr booten, der Superblock wurde nicht mehr erkannt. Vermutlich hätte an dieser Stelle ein fsck gereicht, um alles wieder herzustellen. Aber nachdem meine Kiste in den Tagen zuvor eh sehr instabil war, habe ich an dieser Stelle Tumbleweed wieder durch 13.2 (heute 42.1) ersetzt, alles wieder auf ext4 aufgesetzt und das Backup zurückgespielt.

Das war es dann fürs Erste mit meinen Experimenten, ext4 FTW.

Es ist gut möglich, dass gar nicht btrfs schuld war, sondern Tumbleweed. Schon von der ersten Sekunde an habe ich mich gefragt, wie jemand auf die Idee kommen könne, Tumbleweed auch nur als ansatzweise brauchbar zu bezeichnen, da funktionierte schlicht gar nichts.

Meine ersten Erfahrungen mit btrfs sind eine Katastrophe. Ich lasse jetzt ein paar Jährchen lang die Finger davon.

P.S. (Edit) ich möchte nochmal betonen, dass das meine persönliche Erfahrung ist. Ginge es allen so, wäre btrfs nicht heute schon so beliebt. Da war wohl auch ein Stück Pech dabei. Es wurde halt nach Erfahrungen gefragt, hier ist meine.

[(del676)]

Seit Dezember 2012 auf BTRFS, laeuft 24/7. 0 Probleme bisher.
Debian Wheezy

[Gandharva]

BTRFS stinkt (immer noch)!

Diese Erfahrung musste ich selbst auch machen unter OpenSuse:
http://www.nrtm.org/index.php/2012/03/13/the-joys-of-btrfs-and-opensuse-or-no-space-left-on-device/comment-page-1/

Hier noch die Erfahrungen eines Datenbank Spezis:
http://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp

[(del676)]

BTRFS stinkt, weil der User (oder Suse) zu dumm ist es richtig zu nutzen? Na dann. :rolleyes:

btrfs filesystem df /mountpoint

[Ganon]

Da ich in Arbeitsgeräten meist nur eine Platte habe, sehe ich weniger den Sinn in btrfs. Es kostet da einfach zu viel Performance als das mir die gewonnen Features etwas bringen.

[Tyrann]

Habe btrfs seit April 2014 unter debian sid 24/7 am laufen, bisher gibt es keinen Grund zu klagen. Auf dieser Platte läuft mein VCR, KVM und alle sonstigen Downloads incl. Entpackvorgängen, also ist sehr oft "Betrieb"

[Loeschzwerg]

Wenn die "Features" von btrfs nicht genutzt werden oder von Bedeutung sind => ext4

[Stanger]

Hallo zusammen,
Danke für euere Infos werden wohl erstmal ein BTRFS-Test System aufspielen um zu sehen wie es sich verhält.
mfg
Stanger

[Abnaxos]

Wenn die "Features" von btrfs nicht genutzt werden oder von Bedeutung sind => ext4
Das Feature, an dem ich interessiert war, war (Überraschung!) die Snapshot-Funktion. Dies in erster Linie, um schnell das Dateisystem einfrieren zu können, um dann das (langwierige) Backup zu machen.

Ich habe festgestellt, dass ein rsync auf eine schnelle USB3-Platte eigentlich nur unwesentlich langsamer ist, zumindest, wenn nicht jedes Mal gigantische Dateien involviert sind (Fotografen/Grafiker sehen das also womöglich anders). Was am längsten dauert, ist das Scannen des ganzen Dateisystem-Baums, das muss btrfs aber auch tun.

Daher mache ich das Backup jetzt so: Ich spiegle das Dateisystem mittels rsync auf USB-Platte, von dort aus baue ich dann die inkrementellen Archive und lade sie aufs NAS hoch. Der Snapshot dauert nur wenige Minuten, danach ist der Computer wieder uneingeschränkt benutzbar und der Rest hat Zeit.

Dazu braucht es kein btrfs, für mich ist der Workaround sogar besser.

[Stanger]

OK gute Info. Bei mir ists halt so daß ich ca. 1 TB an Videomaterial in DV und HDV habe und diese so sicher wie möglich archivieren möchte. Ich habe dieses Material zwar noch auf Band im Original vorliegen aber kein Abspielgerät zum erneuten überspielen mehr.

Problem dazu ist noch daß ich nicht weiß wie ich diese 100+ Stunden Material ohne Sichtprüfung so sichern kann und gleichzeitig feststellen kann ob da ein Bit gekippt ist.

Mit brtfs könnte ich wenigstens annähernd ausschließen daß kein weiterer (sofern nicht bereits geschehen) Datenverlust auftritt.

mfg
Stanger

P.S.: Mir ist bewusst daß durch das brtfs Snapshot-System enorme Datenmengen anfallen. Das trifft bei mir insofer nicht zu als daß keine neuen Daten mehr dazu kommen werden. D.h. (korrigiert mich wenn ich da jetzt falsch liege) für mein Datenvolumen von ca. 1 TB fallen "nur" 1 TB Daten als Snapshot auf, in Summe also 2 TB Platz.Das ganze kommt auf eine 4TB Platte also sollte da sowieso kein Platzproblem auftauchen.

[lumines]

Hm, vielleicht sollte man von den Dateien Prüfsummen erstellen und das regelmäßig automatisiert checken. Wahrscheinlich wäre das nur ein Einzeiler. Zusammen mit Backups sollte das schon relativ sicher sein.

Achtung: Halbwissen. Habe nie größere Mengen Daten archivieren müssen.

[Ganon]

Ich weiß jetzt nicht was du für ein Setup vor hast, aber bedenke, dass dir die Checksummen bei Bitflips nichts bringen, wenn du die Daten nicht auf einem RAID hast. Bei einer Platte kann dir btrfs dann auch nur sagen, dass da was kaputt gegangen ist, aber er kann es nicht reparieren.

edit:
gleiches gilt übrigens auch für separate Checksummen. Ohne Backup -> Nutzlos.

edit2:
Wenn du gaaaaanz sicher gehen willst, solltest du übrigens einen PC mit ECC-RAM verwenden, da dir btrfs, bei Checksummen bei kaputtem RAM, die Daten schreddern kann. Ist auch wieder ein Spiel mit Wahrscheinlichkeiten.

[Stanger]

Ah ok, das wäre dann eine Option ich such mal parallel dazu im Netz.
Da ich jetzt nicht um die 10k Files einzeln behandeln kann/will müsste ich das automatisieren können. Danke für den Tip ich such mal....

mfg
Stanger

Sry wenns jetzt ins OT geht aber wenn ich z.B. mit Hashmyfiles mir am Windowsrechner mit NTFS eine Prüfsumme erstelle ist die unter ext4 oder brtfs dann anders ?
-> nach meinem Verständnis schon, zumal das Tool nur für Windowsrechner vorhanden ist.

[Ganon]

Nein, die Prüfsumme einer Datei ist immer gleich, egal wo gespeichert.

[Stanger]

Ja, wollte ich grad editieren sonst müssten ja die ganzen Open Source Projekte x Prüfsummen erstellen. Fehler meinerseits, Danke für den wink ;)

Stanger

[Ganon]

Wenn du übrigens von allen Daten die Checksumme selbst berechnen willst, brauchst du das Tool "shasum". Geht auch mittels openssl sha512 <file>, aber shasum kann hinterher mittels shasum -c alle prüfen.


find /da/wo/die/Daten/liegen/ -type f -print0 | xargs -0 shasum -a 512 -b >> ~/meineDaten.sha512

[Stanger]

Hi,
so, entschuldigung für OT habs jetzt mal runter geschoben. Bitte weiter euere Erfahrungen mit dem brtfs Dateisystem posten.

@Ganon: Bin derzeit noch auf Windows unterwegs um Infos über Linux (mint) und dem brtfs zu sammeln,kann also deinen Tip leider derzeit noch nicht umsetzen.
Hab das aber jetzt unten im Posting angefügt da ja der Threadtitel ums brtfs geht und ich keinen Ärger mit den Mods haben will.

Ich weiß jetzt nicht was du für ein Setup vor hast
Es ist dieses Setup Klick me (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=10941760&postcount=1)
HDD ist eine HGST 4 TB und als Systemplatte ne Samsung Evo 840 mit entweder 120 GB oder 250 GB hab die bereits hier rumliegen.

aber bedenke, dass dir die Checksummen bei Bitflips nichts bringen, wenn du die Daten nicht auf einem RAID hast...Bei einer Platte kann dir btrfs dann auch nur sagen, dass da was kaputt gegangen ist, aber er kann es nicht reparieren
Das würde mir reichen da ausreichend Backups vorhanden sind.

Das ganze ist eher eine temporäre Spielerei da mein derzeitiges NAS - welches derzeit im Raid 5/SHR läuft -(nach derzeitiger Info seitens Synology) kein Firmwareupgrade mehr auf die nächste Version mit brtfs unterstützen wird. -> Support scheinbar nicht möglich da noch 32bit Unterbau und evtl. andere Hintergründe welche jedoch leider nicht offen dargelegt werden.

In Folge dessen warte ich erstmal noch, nach dem release der neuen Firmware, ein Jahr ab bis das ganze dann bei den Endusern gereift ist.
Dann werde ich ein zweites NAS anschaffen welches das erste ablösen wird.

Zudem möchte ich halt auch nimmer von W10 aus meine Privatdaten bearbeiten und den Linux PC aus o.g. Setup dafür nutzen. In der zwischenzeit möchte ich bischen mit Linux und dem brtfs einarbeiten, einfach aus Neugier was da auf einen zukommt.
Besten Dank derweil.

mfg
Stanger

Edit:
Habe von o.g. Datensatz drei Kopien welche ich gerne erstmal untereinander prüfen möchte - bevor ich nächste Woche dann den Linux-Rechner fertig mache und mal brtfs Dateisystem mit Testdaten bespiele und um mich wieder in die Linux Materie einzuarbeiten.
Update: Es sind rund 21 000 Dateien derzeit probiere ich mal das open source tool MD5summer aus, derzeit werden Hashes generiert weiteres muß ich erstmal abwarten....

[Gast]

BTRFS stinkt (immer noch)!

Diese Erfahrung musste ich selbst auch machen unter OpenSuse:
http://www.nrtm.org/index.php/2012/03/13/the-joys-of-btrfs-and-opensuse-or-no-space-left-on-device/comment-page-1/

Hier noch die Erfahrungen eines Datenbank Spezis:
http://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp
Wie bekommt es denn Synology so stressfrei auf ihren Boxen??

[Stanger]

Wie bekommt es denn Synology so stressfrei auf ihren Boxen??

....ääääähm Beta-Test und so......

Stanger

[lumines]

Wie bekommt es denn Synology so stressfrei auf ihren Boxen??

Sie bekommen es genau so stressvoll oder stressfrei auf ihre Boxen wie jeder andere auch.

Auf die Frage, ob btrfs stabil ist, sagen die Entwickler jedenfalls: „Maybe (https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F)“.

[Abnaxos]

Auf die Frage, ob btrfs stabil ist, sagen die Entwickler jedenfalls: „Maybe (https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F)“.
Egal, was genau die Gründe für meine extrem negativen Erfahrungen waren, ob vielleicht die SSD nicht ideal mit btrfs zusammengspielt hat, ob ich gerade einen unglücklichen Kernel hatte, was auch immer es war: Es war da. Ein stabiles FS macht unter keinen Umständen, auch nicht in einem Beta-Kernel, einfach mal so spontan mitten im Betrieb seinen Superblock kaputt. Daher würde ich dazu sagen: Es funktioniert wohl in den meisten Konfigurationen befriedigend bis gut, aber stabil im Sinne von «Ext4-stabil» ist es definitiv nicht.

[Gast]

Sie bekommen es genau so stressvoll oder stressfrei auf ihre Boxen wie jeder andere auch.
SEHR unwahrscheinlich. Ein Fall wie bei Abnaxos könne sie auf garkeinen Fall riskieren. Da wird es kein stressvoll geben, sonst hätten sie das noch nicht rausgebracht. In deren Geschäft kann man sich sowas nicht leisten.

Auf die Frage, ob btrfs stabil ist, sagen die Entwickler jedenfalls: „Maybe (https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F)“.[/quote]
Sagen xfs Entwickler sowas? Ist NTFS stabil? Stabil hat keine Abstufungen. Stabil heißt also nur absolut stabil.

So etwas gibt es in der Softwarebranche eigentlich nicht :D

[lumines]

SEHR unwahrscheinlich. Ein Fall wie bei Abnaxos könne sie auf garkeinen Fall riskieren. Da wird es kein stressvoll geben, sonst hätten sie das noch nicht rausgebracht. In deren Geschäft kann man sich sowas nicht leisten.

Scheinbar können sie es sich leisten, sonst würden sie es ja wohl nicht anbieten.

Sagen xfs Entwickler sowas? Ist NTFS stabil? Stabil hat keine Abstufungen. Stabil heißt also nur absolut stabil.

So etwas gibt es in der Softwarebranche eigentlich nicht :D

Das ist mir schon klar. Deshalb ist dabei „stabil“ eher, dass alle normalen Usecases irgendwie auf möglichst hohe Fehlerfreiheit getestet wurden. Mit btrfs kann das natürlich nicht passiert sein, weil das viel zu wenige Leute benutzen. Es kann gut funktionieren, aber man muss erwarten, dass man auf Fehler stößt. Da kann auch Synology wenig dran ändern.

[Gast]

Oder sie patchen da selbst drin rum. So daß es mit deren Systemen rennt. das wurde über 1 Jahr getestet und es steht überhaupt nicht zur Diskussion, ob sie sich das leisten können oder nicht.
Selbstverständlich können sie sich solche Böcke nicht leisten.

[Gast]

Das Feature, an dem ich interessiert war, war (Überraschung!) die Snapshot-Funktion. Dies in erster Linie, um schnell das Dateisystem einfrieren zu können, um dann das (langwierige) Backup zu machen.

Der eigentliche Vorteil eines Copy-On-Write-Dateisystems wie Btrfs ist die Fähigkeit, ein Snapshot im laufenden Betrieb zu erstellen. Das heißt, alle Programme können während des Backups weiterhin schreibend auf alles zugreifen und man hat trotzdem konsistentes Backup. Rsync reicht da nicht.

[Achill]

Ich habe schon zwei Bier getrunken aber gerade was von Produktivsystem gelesen - also sry bei einen Missverständnis - aber never Test on/with Production! :nono:

Ich würde mir zuerst Gedanken machen was man wirklich will, sprich was bedeutet für mein Szenario:
- Ausfallsicherheit/Redundanz
- Datensicherheit
- Wiederherstellbar

Was bedeutet es für mein Szenario, wenn diese Punkte nicht erfüllt werden (bemerkt man immer erst wenn es passiert ist)?

Wie schnell muss ein Zustand wiederhergestellt werden?

Wie viel darf verloren gehen / was darf verloren gehen / was darf unter keinen Umständen verloren gehen?

Wie kann ich regelmäßig! Testen (das es Funktioniert, etwas was n.m.E. Admins gern nur einmal machen) - im Betrieb (optinal) - das die definierten Kriterien erfüllt werden?

---
Ein Beispiel - ggf. passt das nicht - wie Verhält sich BTRFS bei einer PostgreSQL unter Last? Wenn ein Snapshot erzeugt wird, ist die Konsitenz des Transaktionsbacklock gegeben / kann die DB im Falles eines Ausfalles auf einen anderen System/VM gestartet werden? Kann das überhapt von einen FS gewährleistet werden ...

Alles interessante Fragen - zu Klarstellung - ich bin kein Linux Admin, max. ein halber DevOp - der auch zu Hause mit Debian-Stable und Ext4 rum gurgt (sagt ja wohl alles) :D

[lumines]

Oder sie patchen da selbst drin rum. So daß es mit deren Systemen rennt. das wurde über 1 Jahr getestet

Wenn es denn so einfach wäre. Ein Dateisystem zaubert man (leider) nicht mal eben so aus dem Hut. Andere Unternehmen wie Microsoft oder Apple sitzen an solchen Problemen Jahre oder gar Jahrzehnte. Auch ext4 und xfs sind nicht mal eben vom Baum gefallen.

Was ich damit sagen will: Vermutlich hat Synology den typischen Usecase ihrer Geräte schon ganz gut getestet, aber wahrscheinlich haben sie auch nur abgewägt, ob die ganzen Features eventuelle Fehler aufwiegen.

[Kontrollfreak]

Ein Beispiel - ggf. passt das nicht - wie Verhält sich BTRFS bei einer PostgreSQL unter Last? Wenn ein Snapshot erzeugt wird, ist die Konsitenz des Transaktionsbacklock gegeben / kann die DB im Falles eines Ausfalles auf einen anderen System/VM gestartet werden? Kann das überhapt von einen FS gewährleistet werden ...

Ich würde mal sagen, wenn die DB ein SIGKILL des DBMS überlebt, überlebt sie auch ein Snapshot.

Für hohe Schreiblast sollte CoW (https://btrfs.wiki.kernel.org/index.php/FAQ#Can_copy-on-write_be_turned_off_for_data_blocks.3F) übrigens deaktiviert sein. Sonst fragmentiert's heftig und die Performance kippt. Snapshots funktionieren trotzdem (CoW wird dann nur genutzt, solange der Snapshot existiert).

[Exxtreme]

---
Ein Beispiel - ggf. passt das nicht - wie Verhält sich BTRFS bei einer PostgreSQL unter Last? Wenn ein Snapshot erzeugt wird, ist die Konsitenz des Transaktionsbacklock gegeben / kann die DB im Falles eines Ausfalles auf einen anderen System/VM gestartet werden? Kann das überhapt von einen FS gewährleistet werden ...

Copy on Write-Dateisysteme und Datenbanken sollte man allgemein nicht kombinieren da die Performance massivst in den Keller geht.

[(del676)]

Datenbanken gehoern sowieso auf RAW Devices.

[Ganon]

Nicht jede Datenbank beherrscht den Zugriff auf RAW-Devices (aka -> liefern ihr eigenes Dateisystem mit).

Ein Snapshot für eine Datenbank wäre dann übrigens wie ein Crash der Datenbank. Also dass ein Snapshot immer konsistent ist, ist damit so auch nicht richtig. Das was halt verhindert wird ist, dass dem rsync Daten unterm Hintern weggelöscht werden, bevor er diese kopieren kann. Es garantiert aber nicht, dass alles vollständig geschrieben ist oder abgeschlossen ist. Eine halb geschriebene Videodatei ist auch bei einem Snapshot nur halb geschrieben.

[Liszca]

Hatte BTRFS auf dem Desktop getestet, und meine SSD fühlte sich nur noch wie eine etwas schnellere Festplatte an. Größtes Problem war für mich daß meine daten alle zwei bis drei Tage inkosistent wurden, darauf habe ich das Experiment abgebrochen.

[Gast]

Der eigentliche Vorteil eines Copy-On-Write-Dateisystems wie Btrfs ist die Fähigkeit, ein Snapshot im laufenden Betrieb zu erstellen. Das heißt, alle Programme können während des Backups weiterhin schreibend auf alles zugreifen und man hat trotzdem konsistentes Backup. Rsync reicht da nicht.
Der eigentliche Vorteil von Btrfs ist eine größere Sicherheit gegen bit rots.

Danach kommen Snapshots im laufenden Betrieb.

[Kontrollfreak]

Wenn es nur um Snapshots geht, kann man auch LVM vorschalten (dann aber ohne Btrfs).

[Lord_X]

Habe dieses Weekend auch mal BTRFS angeschaut (Arch Linux). Was soll ich sagen?

root@ph / # btrfs subvolume list / | column -t
ID 257 gen 230 top level 5 path rpool
ID 258 gen 436 top level 257 path rpool/ROOT
ID 259 gen 403 top level 257 path rpool/HOME
ID 261 gen 230 top level 258 path var/lib/machines
ID 277 gen 351 top level 259 path rpool/HOME/.home@20160226
root@ph / #
root@ph / # btrfs subvolume delete home/.home@20160226
Delete subvolume (no-commit): '/home/.home@20160226'
ERROR: cannot delete '/home/.home@20160226': Operation not permitted

^^ Ich bin root! Tags zuvor ging es noch.

In meinen Augen ist es im Vergleich mit FreeBSD und ZFS einfach nur lachhaft! Snapshots sind immer sichtbar und ein Tool wie "beadm" ist nicht vorhanden. Es gibt kein "btrfs snapshot delete <ID>" warum? Ist "/home" nicht gemounted, dann kann ich keinen Snapshot löschen. (Habs zumindest nicht gefunden wie!).

Es ist in der Handhabung gegenüber ZFS (inkl. beadm) einfach nur ... mühsam!

Gruss

[Ganon]

Ist halt auch meine Vermutung. Wenn man btrfs einfach nur "normal" nutzt, so wie man auch ext4 nutzen würde, dann wird das sicherlich alles funktionieren. Wenn man aber gleich anfängt ein RAID5 mit Kompression und Snapshots zu verwenden, dann verwendet man auch automatisch sehr sehr jungen, größtenteils ungetesteten Code.

[Achill]

@Kontrollfreak, Exxtreme, Ulukay, Ganon - war gar nicht meine Intention eine Antwort darauf zu bekommen, mein Post war aber da nicht gut geschrieben, danke mal an der Stelle.

Mir ging es bei meinen Post nur um die geplante Vision und die Usecases und wollte mit der Frage zeigen, wie höhere logische Ebenen ohne weiteres durch ein FS bzw. dessen Feature beeinflusst werden können.

@Stanger, du denkst über den Einsatz von BTRFS zu Hause nach? Geht es darum etwas zu lernen? Oder einfach den Spieltrieb befriedigen ... ;)

Als Idee, ggf. ist ein Blick auf zertifizierte Linux Stacks ganz interessant, wenn z.B. Red Hat BTRFS in Kombination mit einer entsprechenden SLA anbietet, dann könnte man das als Indiz nehmen, dass BTRFS soweit ist - wobei die Erfahrungen hier im Thread nicht so ganz dafür sprechen.

(Open)Solaris mit ZFS in Erwägung gezogen, hat ja ähnliche Features - kann dazu aber nichts weiter schreiben als diesen Vorschlag ... :D

[LordDeath]

Hier gibt es eine interessante und aktuelle Diskussion über ZFS und auch BTRFS wird ziemlich oft mit herangezogen und es artet in ziemlich schlechten Erfahrungsberichten aus: https://news.ycombinator.com/item?id=11125063
Persönlich fand ich dort sehr interessant, dass selbst das angeblich ausgereiftere ZFS noch sehr große Probleme hat: https://news.ycombinator.com/item?id=11128476
(Der Autor ist wohl der Chef von http://rsync.net/)

Bezüglich der BTRFS-Tauglichkeit auf Produktivsystemen muss man außerdem erwähnen, dass OpenSUSE BTRFS nicht als Default für das gesamteDateisystem benutzt: https://www.reddit.com/r/openSUSE/comments/3dambq/why_btrfs_for_but_xfs_for_home/

Beide Dateisysteme werden also noch immer nicht als genauso zuverlässig wie klassische/einfachere Dateisysteme angesehen. ;(

[Ganon]

"sehr große Probleme" und "wenn das Dateisystem voll ist, wird es langsam" ist aber schon ein Unterschied. ZFS ist schon seit Jahren in sehr vielen Datawarehouses im Einsatz. Das ist alles andere als ein "Newcomer". btrfs hat gerade mal vor einem Jahr oder so seinen "please do not use in production" zu "maybe it's stable" geändert.

"Sehr große Probleme" sind eher so Sachen wie "Daten gehen verloren". Und hier hat btrfs schon was vorzuweisen xD

[(del676)]

Beide Dateisysteme werden also noch immer nicht als genauso zuverlässig wie klassische/einfachere Dateisysteme angesehen. ;(

Selbst unter Solaris 11 hat ZFS noch genuegend Bugs ...

[Stanger]

@Stanger, du denkst über den Einsatz von BTRFS zu Hause nach? Geht es darum etwas zu lernen? Oder einfach den Spieltrieb befriedigen ...

Es ist angedacht bzw. läuft, schon das für zu Hause einzusetzen.
Natürlich auch um etwas zu lernen. Der Spieltrieb spielt eher weniger eine Rolle.
Es soll ja letztendlich meine Daten vor Bitfäule schützen.

Der erste Test-Datensatz ist bereits auf dem Home-Laufwerk drauf, derzeit muß ich gerade Linux lernen zu verstehen und meine Wünsche (Konfiguration des User-Accounts) dann umzusetzen. Das OS-Laufwerk mit Linux Mint 17.3 läuft auf ext4 und das Datelaufwerk auf btrfs.

mfg
Stanger

[Acid-Beatz]

Selbst unter Solaris 11 hat ZFS noch genuegend Bugs ...
Definiere Bugs und die weitere Umgebung.
Mir sind Systeme bekannt, die mit ZFS/SAM-QFS bei sehr hohen Durchsatzraten seit rund 8 Jahren fehlerfrei laufen, von dem her kann es nicht so falsch/verbuggt sein.

[Ganon]

Bugs hat jedes Dateisystem. Letztes Jahr hatte ext4 auch in einer Kernel-Version im RAID-Betrieb Daten geschreddert.

Es ist halt immer nur die Frage der Auswirkung. Zerstört der Bug Daten oder wird es nur langsam oder geht irgend eine gewünschte Funktion nicht. Und so Sachen: "Deduplication braucht irre viel RAM" ist kein Bug, das ist einfach ne Tatsache die sich nicht vermeiden lässt.

ZFS ist nicht perfekt, klar. Aber es ist momentan das einzige plattformübergreifende Checksummen-Dateisystem, welches man relativ sorglos den Stempel "Production ready" aufdrücken kann.
Das ist bei BTRFS nicht so, wenn selbst die Entwickler sagen "Maybe". Da kann noch so oft jemand kommen und sagen: "Bei mir läuft's". btrfs muss einfach noch reifen. Auch wenn es von vielen als "Broken by design" angesehen wird, will ich jetzt btrfs jetzt nicht allgemein als schlecht hinstellen. Es ist halt nur noch nicht "fertig".

Windows hat noch ReFS, aber man kann noch nicht davon booten und ist halt Windows Only.

edit:
Ich hätte auch nichts gegen ein Linux-Dateisystem welches ohne Deduplication und Co kommt und nur Checksummen bietet als extra Feature. Quasi ext4+Checksummen. Aber da müsste es dann sicherlich für die Selbstheilung noch Anpassungen geben um mit mdadm zu reden. Weil ohne RAID sind Checksummen halt sinnlos.

[Ganon]

ZFS hat halt ein "großes" Problem. Fehlende Blockpointer Rewrites. 2013 hat sich auch mal ein damaliger Sun-Entwickler dazu geäußert und gemeint, es sei prinzipiell möglich, dass in ZFS zu implementieren, es sei dann aber das letzte Feature was ZFS je bekommen würde. Die Komplexität sei hinterher so groß, dass es dann irre schwer wäre neue Features hinzuzufügen.

Dass das fehlt ist dann quasi die Ursache dafür dass Dinge wie RAIDZ erweitern, Defragmentierung und Pool neu balancieren nicht möglich sind.

"Problem" ist aber auch, dass so ein großes Datawarehouse (immerhin die Hauptförderer von ZFS) damit an sich keine Probleme hat. Einfach für ein paar tausend EUR mal eben neue RAID-Zs hinzufügen ist kein Ding. Fragmetierung ist auch weniger ein Problem, man schiebt die Daten eh dauernd hin und her. Da defragmentiert sich das ganz von alleine. Entsprechend haben die Geldgeber kein Interesse daran dafür Geld auszugeben.

Somit haben die Probleme nur Heimanwender und kleinere Betriebe denen der Speicher vom Homeserver ausgeht. Es bleibt halt nichts anderes übrig als komplett ein neues Set an Platten hinzufügen. Das geht halt ins Geld.

btrfs verfügt über Blockpointer Rewrites und hat die Probleme somit nicht. Rebalancing geht, Defragmentierung geht, Dataset Erweiterung geht auch. Aber gerade die Punkte sind alle ebenfalls noch seeeeeehr jung.

[Gast]

an alle, die btrfs schon nutzen/genutzt haben:
nutzt ihr das für die komplette platte (also ohne sie vorher zu partitionieren), evtl mit subvolumes oder konventionell mit mbr/gpt und einer partition?
was sind die vorteile, das so zu machen? wie funktioniert der bootvorgang, legt btrfs selbst ein mbr an?
uefi boot geht dann ja nicht. inwiefern ist das nachteilig, wenn man kein secure boot braucht? wofür braucht man überhaupt uefi?

[Lord_X]

nutzt ihr das für die komplette platte (also ohne sie vorher zu partitionieren), evtl mit subvolumes oder konventionell mit mbr/gpt und einer partition?
Immer mit einer Partition! Das gilt auch für ZFS (Hier rede ich von OpenZFS welches bei FreeBSD etc. verwendet wird). Grub dann in den MBR und fertig. Grub kann BTRFS Partitionen lesen und dann dort den Kernel starten. Partitionen müssen auch nicht das "BootFlag" haben.

was sind die vorteile, das so zu machen?
Vorteil ist, dass wenn eine HDD kaput geht, du sie durch ein anderes Modell ersetzen kannst. Nicht immer sind Festplatten unterschiedlicher Hersteller gleich gross, auch wenn es nur ein paar Sektoren sind.

[iuno]

Ich hatte auch immer normal partitioniert. Alleine schon, damit ich eine swap Partition haben kann und aus sonstigen Gruenden, warum man eben Partitionen haben will. Ich weiss auch gar nicht, was besser ueberhaupt besser werden soll, wenn man direkt ein btrfs direkt auf der Platte erstellt.
bzgl UEFI - BIOS: wenn du kein dual-boot hast ist das ganz ehrlich voellig egal. Es kommt immer die Behauptung auf, uefi boote schneller. Das macht aber lt. meiner Erfahrung quasi keinen Unterschied. Viel bedeutender sind da das Mainboard/bios selbst. Manche sind einfach super langsam, manche sehr schnell, je nachdem wie viel "Extras" dabei sind. uefi hat mehr bloat und potenzielle Sicherheitsprobleme. ohne secure boot haette das imho gar keine Daseinsberechtigung

[Stanger]

nutzt ihr das für die komplette platte (also ohne sie vorher zu partitionieren)

Ja, eine komplette Platte als eine Partition als /home@btrfs. OS Platte läuft auf ext4 (eigene SSD) und /swap ist auf ebenfalls auf einer eigenen SSD.

mfg
Stanger

[iuno]

was jetzt, Partition oder nicht? ;)
hast du z.B.
mkfs.btrfs /dev/sdc
oder
mkfs.btrfs /dev/sdc1
gemacht?

[fezie]

edit:
Ich hätte auch nichts gegen ein Linux-Dateisystem welches ohne Deduplication und Co kommt und nur Checksummen bietet als extra Feature. Quasi ext4+Checksummen. Aber da müsste es dann sicherlich für die Selbstheilung noch Anpassungen geben um mit mdadm zu reden. Weil ohne RAID sind Checksummen halt sinnlos.

ext4 unterstützt zumindest für die Metadaten Checksummen.
Mit den kommenden e2fsprogs 1.43 wird das metadata_csum feature standardmäßig angeschaltet.
Ich nutzt es problemlos. Allerdings mit aktuellem 4.4er Kernel.

[Ganon]

XFS unterstützt auch schon seit langem Metadaten Checksummen, aber das ist halt nichts halbes und nichts ganzes. Automatisch Reparatur ist da auch nicht drin.

[Gast]

Warum ist das nichts halbes, wenn ein Problem erkannt wird, was sonst nicht erkannt worden wäre? Warum muß man das schlecht reden?
Was hat das nochmal mit der Automatik auf sich, in den eigenen 4 Wänden?

Jahrzehnte waren wir froh Images mit Ghost und dann vergleichbarem gemacht zu haben, wenn unsere HDs unerwartet das zeitliche segneten.
2016 sind Metadaten Checksumms nichts halbes und nichts ganzes, weil nur damit noch keine automatische Reparatur möglich ist?

Ist das Problem vielleicht ein ganz anderes? Vor 15 Jahren schon hab ich damit aufgehört mich im Netz ohne aufzuspielen, indem ich mich über aufgeschnappte highend Features informeirte und sie dann ohne für mich realen Nutzen forderte. Womit ich zeigen konnte wie gut ich mich mit highend auskenne und wie edel hochwertig meine Ansprüche sind.

Ok, zugegeben ich komme mir nicht weitgehend nur wegen 3DC so vor, als wenn ich weiterhin ein Vorreiter dieses Trends wäre.

[(del676)]

Schade, dass man hier keine Likes vergeben kann. :)

Uebrigens funktioniert btrfs auf Linux Minut am PC meiner Mutter seit 2 Jahren einwandfrei.
Bei jedem Start des PCs wird ein Snapshot angelegt. ;)

[Ganon]

Damals waren die Festplatten auch noch viel einfacher (geringere Informationsdichte), SSDs gab es nicht. Und heute braucht bei einer SSD nur mal die Firmware kaputt sein und durch TRIM ein paar Daten schreddern. Oder du hast die SSD mal 3 Monate nicht am Strom -> Datenverlust. Gab es alles schon. Festplatten werden auch nicht hochwertiger. Eine leise sterbende Festplatte -> Pech.

Du kannst auch wieder zurück zu DOS mit FAT16 gehen, wenn dir neue Technologien nicht zusagen und du sie nicht haben willst. ;) ZFS hat halt für mich vor 8 Jahren (!) die Messlatte nach oben gesetzt. Wenn es um Langzeit-Datenspeicherung geht, dann will ich nichts geringeres mehr haben.

Und von mir aus kann hier jeder schreiben, dass btrfs bei ihm läuft, wenn er das im Single-Disk Modus betreibt ;) Das macht den RAID5/RAID6 Modus nicht stabiler.

Ich rede übrigens Metadaten Checksummen nicht schlecht. Klar, es verhindert, dass bei einem Fehler in den Metadaten noch mehr kaputt geht. Aber das war's halt auch schon. Ein Spezialfall eines Spezialfalls abgedeckt... ganz großes Kino ;)

edit:
Und "edel hochwertige" Ansprüche, hätten der Person hier auch geholfen:

https://blog.barthe.ph/2014/06/10/hfs-plus-bit-rot/

Nur weil dir deine Daten egal sind, muss das ja nicht für alle gelten.

[Exxtreme]

Und von mir aus kann hier jeder schreiben, dass btrfs bei ihm läuft, wenn er das im Single-Disk Modus betreibt ;) Das macht den RAID5/RAID6 Modus nicht stabiler.

Naja, Raid 3/4/5/6 sollte man IMHO eh' meiden. Daran würde ich nie ein Dateisystem messen wie gut es mit diesen Modi zurechtkommt. Und ich hätte auch Verständnis wenn die FS-Macher diese Modi stiefmütterlich behandeln und sich lieber um wichtigere Baustellen kümmern.

[(del676)]

Zumal SWRaid ohnehin vom Kernel ausgezeichnet unterstuetzt wird.
Ich wuerde niemals auf die Idee kommen, einem Filesystem unter Linux das Raid anzuvertrauen. Wofuer gibts ein saustabiles und schnelles md sonst?

[Ganon]

btrfs auf md ist ja noch dämlicher... da schaltet man ja sämtliche Selbstheilungsfunktionen ab. Da kann man es auch gleich lassen und sich den Mega-Performance-Einbruch durch btrfs sparen. Snapshots gibt's via LVM.

md von Linux ist ziemlich dumm... Sektorfehler werden ignoriert und auch nicht repariert. Informationen über Defekte werden auch nicht an das Dateisystem weitergeleitet. Auch wenn dmesg mit DMA Errors nur um sich wirft meldet mdstat auch gerne "alles in Ordnung". Gegen Bitrot schützt es auch nicht. md hilft nur wenn ganze Platten komplett aussteigen. Nicht wenn sie leise kaputt gehen.

ZFS meldet hier schon im Vorfeld, dass de Platte möglicherweise demnächst aussteigt.

Kann ja im Endeffekt jeder mit seinen Daten machen was er will...

[(del676)]

Sicher wieder Gelaber und Rumsempern von Ganon. Nichts ist gut genug fuer unseren Forumelitisten.

Du bist auf Ignore, also spar Dir das Antworten (zumindest auf meine Posts.)
Danke!

[Ganon]

Ja ich mein, ich kann auch technischer werden, aber ich weiß nicht warum man technischer auf "bei mir läuft's" und "md ist super, man braucht nichts besseres" antworten sollte. ;)

Wenigstens muss ich nicht "fick dich du arrogantes Arschloch" per PMs rumschicken, um Argumente zu untermauern ;)

[Ganon]

Naja, Raid 3/4/5/6 sollte man IMHO eh' meiden.

Das Problem ist: Wie kriegt man sonst halbwegs sicher viel Speicher? Ganz viele Mirrors sind halt teurer als ein RAID5. RAID 5 bzw. 6 ermöglicht es dir halt bei beliebig vielen Platten von diesen nur 1 bzw. 2 für Redundanz zu opfern.

Daher gerade für mich als Heimanwender mit vielen Daten führt da kein Weg dran vorbei.

Ein Freund von mir fährt halt auch lieber die Variante JBOD und macht dann lieber ständig Backups. Aber das geht halt auch ins Geld und Bitrots können auch nicht direkt geheilt werden.

[Stanger]

was jetzt, Partition oder nicht? ;)
hast du z.B.
mkfs.btrfs /dev/sdc


This !


Hier geht´s ja richtig zur Sache, schade das ich mangels finanzieller Resourcen für ´nen KVM momentan nicht an den Linux-Rechner kann.
Werde aber sobald als möglich dann hier posten.

mfg
Stanger

[Ganon]

Ja wie schon gesagt wurde, man sollte es vermeiden, dass Dateisystem auf den kompletten Datenträger zu spannen. Man sollte eigentlich immer eine GPT-Partition anlegen.

Das hat mehrere Gründe:
- Festplattentools und Windows erkennen die Platte als "da ist ein Linux-Dateisystem", anstatt "da ist nichts". Ein Verklicker irgendwo und die Daten sind futsch.

- im RAID Fall erleichtert es den Austausch von Festplatten, da man bei einer GPT-Partition sagen kann: "Du bist jetzt wirklich 2000000000000 Byte groß", statt 2000000234312 was immer so Produktionsungenauigkeiten zwischen Herstellern ist.

- Alignment Anpassungen sind etwas direkter zu Erkennen / Durchzuführen.

[Loeschzwerg]

RAID5 ist doch super bei einem NAS bzw. kleinerem Storage.

Bezüglich btrfs evtl. interessant:
http://www.computerbase.de/2016-03/synology-dsm-6.0/2/

Bereits mit dem DSM 5.2 hat Synology wie erwähnt neue NAS-Modelle zusätzlich zum ext4-Dateisystem mit der Unterstützung für das Copy-On-Write-Dateisystem btrfs bedacht. Das erste Tower-NAS mit btrfs-Unterstützung war die DS716+.

Durch btrfs wird die Datensicherheit erhöht, indem die gespeicherten Daten mittels Prüfsummen bei jedem Leseprozess auf ihre Integrität geprüft werden, wodurch Datenkorruption verhindert wird. Synology unterstützt dabei jedoch nur die Erkennung von Fehlern, nicht deren Korrektur. Die Bit-rot-Correction von btrfs wird demnach nicht unterstützt. Synology hat aber angekündigt, an einem eigenen Korrektur-Algorithmus zu arbeiten, der effizienter sein soll als die in btrfs integrierte Funktion.

Standardmäßig ist die Copy-On-Write- und Prüfsummen-Funktion von btrfs beim Erstellen eines Freigabeordners aktiviert, sie kann bei Bedarf jedoch manuell ausgeschaltet werden. Wie im Test der DS716+ gezeigt, ist dies jedoch bei den Modellen, die btrfs überhaupt unterstützen, nicht notwendig, da die Leistungseinbußen zu vernachlässigen sind.

[Ganon]

RAID 5/6 wird aus btrfs vielleicht erst mal wieder entfernt. Der bisherige Wiederherstellungscode ist fehlerhaft und funktioniert nicht im Fehlerfall:

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg55161.html

http://phoronix.com/scan.php?page=news_item&px=Btrfs-RAID-56-Is-Bad

Für alle die btrfs mit RAID5/6 benutzen: Backup! Im Fehlerfall könnte btrfs eure Daten schreddern!

[Gast]

Wie ist denn der aktuelle Status von BTRFS?

Ich wollte mir eigentlich einen eigenen Server (z.B. FreeNAS) aufsetzen. Da ich aber Familie und sehr wenig Zeit habe, fahre ich evtl. doch besser mit einem Synology oder QNAP NAS.
Taugt mittlerweile BTRFS? Oder besser nicht? RAID hätte ich ohnehin nicht vor...


Ach ja, was ist von diesem Artikel zu halten:
https://nctritech.wordpress.com/2017/03/07/zfs-wont-save-you-fancy-filesystem-fanatics-need-to-get-a-clue-about-bit-rot-and-raid-5/

Hatte den glaube ich hier gefunden: https://forum.qnap.com/viewtopic.php?t=136118

[Ganon]

Taugt mittlerweile BTRFS? Oder besser nicht? RAID hätte ich ohnehin nicht vor...

Wenn du nicht vor hast ein RAID aufzubauen, dann besteht nicht unbedingt Bedarf nach btrfs oder ZFS. Klar gibt es noch so kleinere Features wie Dateisystemkomprimierung, aber hier musst du dann überlegen, ob das was bei dir bringt. Für Videos und Fotos bringt das im Großen und Ganzen nichts.


Ach ja, was ist von diesem Artikel zu halten:
https://nctritech.wordpress.com/2017/03/07/zfs-wont-save-you-fancy-filesystem-fanatics-need-to-get-a-clue-about-bit-rot-and-raid-5/

Der Artikel lästert im Großen und Ganzen über all die Sicherheitsmaßnahmen, sagt dass du die auch mit Hardware erschlagen kannst und redet halt die Wahrscheinlichkeit eines Defekts runter. Also so in etwa: "Hier würde dich ZFS retten, aber das passiert dir eh nicht".

Man kann auch ausrechnen, dass ein Flugzeug statistisch ein sehr sicheres Verkehrsmittel ist. Wenn du aber in einem sitzt, was gerade abstürzt, dann hat dir die Statistik auch nicht geholfen und wird dir auch nicht helfen.

Und wenn man sagt "Die Hardware macht das schon", dann vertraut man der Hardware schon ein ganz schön starkes Stück (man erinnere sich an fehlerhaften TRIM-Implementierungen in SSDs). Ich vermute der Autor will nur aussagen, dass man Backups machen soll. Imo übersieht er, dass ZFS auch bei Backups eine sehr große Hilfe ist...

Mich persönlich hat ZFS schon diverse Male vor der ach so perfekten Hardware gerettet (RAM kaputt, Kabel kaputt, Bitflips, Platte schreibt blödsinn ...), dass ich Kritik am System nicht nachvollziehen kann.

Im Endeffekt darf jeder mit seinen Daten machen was er will. Wenn jemand meint, der ganze Aufwand sei Humbug, dann hält ihn niemand davon ab sein so System so aufzubauen wie ihm das gefällt.

BTRFS scheint aktuell im Single-Disk und RAID0 und RAID1 betrieb ganz gut zu funktionieren. RAID5/6 ist wohl immer noch eine ziemliche Baustelle.

[Exxtreme]

Was BTRFS angeht, kein Plan ob das eine große Zukunft hat.

Red Hat hat sich offiziell davon verabschiedet:
https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/

Und Oracle will da offenbar auch nicht mehr so recht.

[Ganon]

Man munkelt ja so ein bisschen, dass Oracle überlegt ZFS eine neue Lizenz zu verpassen. Da sie Solaris mehr oder weniger begraben haben und nur noch recht langen Long-Term-Support leisten, ist eine Out-Of-Tree Handhabung von ZFS natürlich relativ teuer und schwer an den Kunden zu verkaufen. Sie selbst verticken ja auch nur ein umbenanntes RedHat Linux. Man darf auch nicht vergessen: OrcaleZFS ist nicht OpenZFS.

BTRFS wurde ja schon mehrfach als "broken by design" angesehen. Inwieweit das stimmt ist natürlich fraglich, aber es zeigt sich ja auch ein bisschen, dass man sich an Dingen wie RAID5/6 mehr oder weniger die Zähne ausbeißt.

Ein anderer Vertreter ist bcachefs, welcher aber noch keinen produktiven Status erreicht hat.

Ansonsten steht noch die Veröffentlichung des Sourcecodes von APFS von Apple aus. Kann man zwar nicht in die Kategorie der Checksummen-Dateisysteme packen, hat aber viele andere Features "der Großen". Hier braucht's dann aber natürlich auch jemanden der Lust hat den Code nach Linux zu portieren.

Von Microsofts ReFS hört man ja leider auch nicht allzu viel und ist hinter teuren Windows-Versionen verschlossen.

[Metal Maniac]

Wir werden demnächst ein BTRFS im RAID10 unter Debian 9 als Ablagesystem in Betrieb nehmen. Die einzelnen Devices bestehen dabei aus iSCSI-LUNs. Bisher war's bei den Tests ziemlich stabil, trotz entfernen einzelner LUNs oder Storage Arrays im laufenden Betrieb oder Kaltstart des Servers.

Performance scheint auch zu passen, selbst wenn man ein paar Millionen Verzeichnisse und Dateien anlegt und den Scrub drüberlaufen lässt.

Was RedHat angeht glaube ich nicht dass deren Vorgehen viel Aussagekraft über BTRFS hat. RHEL basiert immer auf einer bestimmten Linux Kernel-Version. Da BTRFS teil des Linux-Kernels ist müssten die jede neue Version rückportieren, da kann ich schon verstehen, dass die das rauswerfen. SUSE z.B. hat BTRFS seit SLES 12 als Default-Filesystem drin.

[Ganon]

Im Dauerbetrieb nicht vergessen, dass btrfs manuell neu ausbalanciert werden muss. Per Cronjob oder ähnlichem. Ansonsten streikt das Dateisystem irgendwann.

[Metal Maniac]

Sollte eigentlich nur bei einer Erweiterung notwendig sein (Restripe), ansonsten ist keine regelmäßige Ausführung notwendig:
https://btrfs.wiki.kernel.org/index.php/FAQ#Do_I_need_to_run_a_balance_regularly.3F

Bis Version 3.14 musste man das noch regelmäßig durchführen, um ein irrtümlich als voll markiertes Filesystem zu verhindern, das ist aber inzwischen behoben.

Bei BTRFS muss man genauso wie bei Samba, mit dem ich mich auch sehr ausführlich beschäftigen durfte, aufpassen, was man als Doku dazu liest und auf welche Version das bezogen ist. Das meiste ist hoffnungslos veraltet und kann getrost ignoriert werden. Am besten hält man sich an die Doku der offiziellen Seiten, selbst Bücher sind teilweise schon veraltet, wenn sie rauskommen.

[Ganon]

Gut, "hoffnungslos veraltet" ist relativ bei der Menge an LTS-Distributionen mit Kernel <=3.14 :D Aber gut, bei Debian 9 ist das dann wohl nicht mehr nötig. Bei RedHat aber wohl noch.

Mir ist btrfs bei dem Thema noch zu heiß. :D Ich fahre erst mal weiterhin ZFS@FreeBSD oder eben klassisch mdraid + "normales" Dateisystem unter Linux.

[Metal Maniac]

Gut, "hoffnungslos veraltet" ist relativ bei der Menge an LTS-Distributionen mit Kernel <=3.14 :D Aber gut, bei Debian 9 ist das dann wohl nicht mehr nötig. Bei RedHat aber wohl noch.
Stimmt, ist ja nicht überall so, dass man frisch auf der grünen Wiese anfangen darf wie in meinem Fall ;).
Mir ist btrfs bei dem Thema noch zu heiß. :D Ich fahre erst mal weiterhin ZFS@FreeBSD oder eben klassisch mdraid + "normales" Dateisystem unter Linux.
Kann ja meine Erfahrungen hier reinschreiben, wenn's was Interessantes zu berichten gibt. Übrigens: Was man auf alle Fälle bei BTRFS nicht vergessen sollte ist den Scrub-Prozess regelmäßig laufen zu lassen, um die Integrität der Daten zu prüfen (der nudelt letztendlich einfach die ganzen Checksummen durch).

[Exxtreme]

Performance scheint auch zu passen, selbst wenn man ein paar Millionen Verzeichnisse und Dateien anlegt und den Scrub drüberlaufen lässt.

Datenbanken würde ich da nicht drauf betreiben. Copy on write ist Gift für die Performance wenn Daten oft geändert werden müssen.

[iuno]

Was BTRFS angeht, kein Plan ob das eine große Zukunft hat.

Red Hat hat sich offiziell davon verabschiedet:
https://www.theregister.co.uk/2017/08/16/red_hat_banishes_btrfs_from_rhel/
Man sollte die Nachricht aber auch nicht ueberbewerten. RHEL hat lange Supportzyklen und offenbar fehlen RH einfach Leute, die mit btrfs zu tun hatten. Die lead devs sind schon vor Jahren von RH zu Facebook gegangen. Weil es noch so jung ist, viele Baustellen hat gibt es natuerlich immer recht viele Aenderungen. Dann alles fuer RHEL backporten und rebasen ist ein Haufen Arbeit, den man so nicht haben will. Ist ja auch verstaendlich, heisst aber nicht automatisch dass btrfs keine Zukunft hat.

[Gast]

Wenn du nicht vor hast ein RAID aufzubauen, dann besteht nicht unbedingt Bedarf nach btrfs oder ZFS. Klar gibt es noch so kleinere Features wie Dateisystemkomprimierung, aber hier musst du dann überlegen, ob das was bei dir bringt. Für Videos und Fotos bringt das im Großen und Ganzen nichts.


Verständnisfrage:
Im Fall von ZFS funktioniert dann dennoch Bit Rot Erkennung oder?
Würde für Bit rot Korrektur auch ein Backup in Form eines Snap-Shots reichen, sofern es keine Datenänderung gab (es gibt Daten, die wenig geändert werden, häufig sind das Mediendaten).

Das Problem ist: Wie kriegt man sonst halbwegs sicher viel Speicher? Ganz viele Mirrors sind halt teurer als ein RAID5. RAID 5 bzw. 6 ermöglicht es dir halt bei beliebig vielen Platten von diesen nur 1 bzw. 2 für Redundanz zu opfern.

Daher gerade für mich als Heimanwender mit vielen Daten führt da kein Weg dran vorbei.

Ein Freund von mir fährt halt auch lieber die Variante JBOD und macht dann lieber ständig Backups. Aber das geht halt auch ins Geld und Bitrots können auch nicht direkt geheilt werden.

Mirror (z.B. bei ZFS) finde ich schon interessant, wenn man nicht allzuviel Speicher benötigt, z.B. "nur" 4 oder 6 TB. HDDs gibt es in den Größen.
=> Dann hat man nur 2 HDDs gegenüber einem RAIDZ1 oder 2
=> Günstiger in Anschaffung und Stromverbrauch.

[Ganon]

Verständnisfrage:
Im Fall von ZFS funktioniert dann dennoch Bit Rot Erkennung oder?
Würde für Bit rot Korrektur auch ein Backup in Form eines Snap-Shots reichen, sofern es keine Datenänderung gab (es gibt Daten, die wenig geändert werden, häufig sind das Mediendaten).

Bit Rot Erkennung funktioniert dann, klar. Aber Behebung nicht. Ein Snapshot ist keine sofortige Kopie der Daten. Du hast erst eine Kopie wenn diese geändert wurde und dann auch nur von den Blöcken die geändert wurden. D.h. maximal dein alter Snapshot und damit die alte Version wäre noch verfügbar.

Du kannst aber sowas machen wie "zfs set copies=2". Dann speichert ZFS jeden Block 2 mal ab. Damit hast du dann aber natürlich doppelten Speicherverbrauch.

[Gast]

Btrfs Status: https://btrfs.wiki.kernel.org/index.php/Status

RAID56 & Btrfs ist kritisch.

RAID1 & Btrfs z.B. scheint laut obiger Tabelle und diversen Aussagen rund bzw. problemlos zu laufen.

Offenbar gilt auch: Wenn Btrfs, dann ziemlich aktueller Kernel.

[Gast]

Wie verträgt sich denn "Scrub" mit Spindown?

[vanquish]

Scrub erzeugt Plattenzugriffe. Ergo wird die Platte ggf. aus dem Spindown aufgeweckt bzw. so lange Zugriffe auf die Platte erfolgen der Spindown verhindert. Scrub macht nichts anderes als Daten zu lesen und diese mit den abgespeicherten Prüfsummen abzugleichen.

[Gast]

Ein anderer Vertreter ist bcachefs, welcher aber noch keinen produktiven Status erreicht hat.


https://bcachefs.org

Copy on write (COW) - like zfs or btrfs
Full data and metadata checksumming
Multiple devices, including replication and other types of RAID
Caching
Compression
Encryption
Snapshots
Scalable - has been tested to 50+ TB, will eventually scale far higher
Already working and stable, with a small community of users


=> Interessant.