DSM 6.x und darunter Welches Dateisystem empfehlt ihr "btrfs" oder "ext4"

[tproko]

kommt (bisher) nicht zum Ziel:

Zur Frage btrfs vs. ext4:

Genau, also ich versuche jetzt mal einen Linux USB Stick zu erhalten.

Stand heute würde ich zu ext4 tendieren, da das einfach schon gefühlt seit Ewigkeiten läuft für Desktop und Server, und btrfs doch etwas neuer ist.
Habe mich damals auch für btrfs entscheiden, aber den großen Nutzen noch nicht gefunden für mich.

 

[Heidi]

@Mettigel hatte meine 218+ auch zu einer 418play migriert, obwohl das damals eindeutlig auf der Homepage als "nicht unterstützt" aufgeführt wa.r Hatte das dem Support damals auch so mitgeteilt... k.a.?

 

[Heidi]

Habe mich damals auch für btrfs entscheiden, aber den großen Nutzen noch nicht gefunden für mich.

Auch @tproko: Natürlich kann man sich an den vielen Features von BTRFS freuen (Snapshot, copy-on-write, Versionierung, Komprimierung). Muss man aber nicht.

Natürlich kann man sich im Gegenzug darüber ärgern, dass die Performance (unmerklich!) schlechter ist und dass man effektiv von der HDD deutlich (!) weniger Platz nutzen kann. Muss man aber nicht.

Aber der große Nutzen für dich ist: ...Trommelwirbel.... Die Datenintegrität, die dem ext4 (gehört zur Generation der "dummen" FS) deutlich überlegen ist.

Auf einer single-HDD hast du

im Index-Bereich

• 1) Fehlererkennung
• 2) Selbstheilung

Im Datenbereich

• 1) Fehlererkennung

Im Raid1-Betrieb hast du

• 1) Fehlererkennung
• 2) Selbstheilung

Im Datenbereich

• 1) Fehlererkennung
• 2) Selbstheilung

Also schon im single-HDD Betrieb gepaart mit einem vorhandenen Backup sind unentdeckte write-Errors und Bitflips abgesichert. Man sollte heutzutage in Bezug auf Dateisicherheit NICHT mehr auf ein altes filesystem gehen. Die vielgepriesene Performance ist in der heutigen Zeit mit der ultraschnellen hardware doch kein richtiges Argument mehr! In Zukunft mit den dann billigeren SSDs sowieso kein problem mehr (Apropos: Den Magnetischen Bitflip wird es dann nicht mehr geben, wohl abder den elektrischen Leak).

Anmerkung: Dienste wie ActiveBackupForBusiness (auch für privat!) werden nur auf dem BTRFS unterstützt...

 

[tproko]

Die Datenintegrität, die dem ext4 (gehört zur Generation der "dummen" FS) deutlich überlegen ist.

Hi, danke für deinen ausführlichen Post!
Das mit der Datenintegrität ist mir durchaus bewusst, die "Selbstheilung" via Raid1/5/6 kam dann auch nachträglich irgendwann mal in die Syno DSM rein (zumindest hätte ich das jetzt so im Kopf, am Anfang war es nur ein Hinweis).

Ich schrieb ja explizit, den Nutzen für mich habe ich noch nicht gefunden Es gibt ja hier im Forum einen Thread, wo @ottosykora, andere und ich versuchten btrfs Raids wieder herzustellen via Linux USB Sticks. Alles nicht ganz so einfach wie mit ext4. Falls ich mal korrupte Daten habe, bin ich natürlich sicher froh darüber!

Nachdem wir im Haus für eine kleine Verwaltungsoberfläche in kürze Postgres via Docker auf der DS416play nutzen, wird sich dann eh zeigen, was hier wirklich limitierend ist bei meiner kleinen NAS (CPU - eher wahrscheinlich; oder doch btrfs - eher nicht bei meinen Mini Mengen )

Wäre mal interessant, ob es hier schon Benutzer gibt, die diese Selbstheilung der Syno erlebt haben Gibt es da dann Logs/Mails/Hinweise? Spannende Sache.

 

[Heidi]

Wäre mal interessant, ob es hier schon Benutzer gibt, die diese Selbstheilung der Syno erlebt haben

Wenn du dein System in einem Raid fährst, geschieht die Selbstheilung on-the-fly beim Lesen. Prinzipiell wird der Hash-Abgleich ja bei JEDEM Lesevorgang durchgeführt. Man dürfte also (leider oder zum Glück) das niemals feststellen.

Nur wenn man nicht im Raid ist, gibts halt einen kann-nicht-lesen-error. Das wäre ein Hinweis für eine korrupte File. Aber dann ist ja keine Selbstheilung am laufen... Und die Selbstheilung im Index-Bereich des FS bekommt man (s.o.) nicht mit.

Ich hatte vor Monaten Kontakt mit dem Support um nochmal zu klären ob Synology die BTRFS schwächen (siehe btrfs-wiki) ausgemärzt haben. Ja haben sie (das Synology BTRFS funktioniert anders als das Standard BTRFS) und ob die Selbstheilung dann auch in Verschlüsselten Ordnern funktioniert (weil dort drin ja das CryptFS arbeitet). Ja tut es.

 

[tproko]

geschieht die Selbstheilung on-the-fly beim Lesen

Genau, ich hätte dazu aber trotzdem gerne eine Meldung in DSM: "Datei xy war korrupt, wurde aber repariert". Mal schauen, ob irgendwann jemand dann damit Erfahrungen macht.

BTRFS schwächen

Das sind keine Schwächen, BTRFS kann kein Raid5/6. Nur Raid1 wird unterstützt (aber nicht von Syno verwendet).
Synology verwendet BTRFS als Filesystem. Für das (Software-)Raid darüber wird mdadm + lvm genützt. Also Fehler ausgemärzt haben sie nicht, sie verwenden einfach kein BTRFS Raid

 

[H3llF15H]

Btrfs ist auch der Grund, weshalb ich nun mit meinem Storage zu Synology wechseln werde. Mir ist auch einfach die Datenintigrität wichtig und das nicht nur bis übermorgen, sondern auch weit in die Zukunft gedacht.

 

[Heidi]

Das sind keine Schwächen, BTRFS kann kein Raid5/6

Das is m.W. nach nicht ganz korrekt. Raid5 geht schon.
Es kann nur in gewissen Szenarien (explizit: Stromausfall bei aktiveirtem Schreibcache) zur erstellung einer falschen Parität kommen, sodass der raid-recovery fehlschlägt. Das ist bis heute nicht behoben. Als dauer-workaround empfehlen sie im btrfs-wiki nach einem Stromausfall und auch sonst öfters ein Data-Scrubbing durchzuführen, bei dem die parität neu berechnet wird. Klar, für mich auch ein klares NoGo.

sie verwenden einfach kein BTRFS Raid

Ja, das habe ich damals vom Support auch so erfahren. Lies:

Guten Morgen,

vielen Dank, dass Sie den Technischen Support von Synology kontaktieren und entschuldigen Sie die verspätete Rückmeldung.

Synology nutzt kein BTRFS-RAID5 sondern BTRFS (FS Layer), mdadm und standart VG.
Es wird hier eine modifizierte mdadm und btrfs version genutzt um trotzdem die BTRFS Heilung mithilfe von Raid Paritäten zu nutzen.

Sollten Sie sonstige Fragen, Anregungen oder Kritik haben, können Sie sich gerne jederzeit an uns wenden.

ich hätte dazu aber trotzdem gerne eine Meldung in DSM: "Datei xy war korrupt, wurde aber repariert"

Das Filesystem selbst liefert (noch) keine Schnittstelle, diese Info weiterzugeben... Da kann Synology nix für. Und solange die sehr seltenen Bitflips damit behoben werden, kümmert das wenig. Wenn die Platte vermehrt Hardware Fehler bringt, deckt das SMART auf. Aber ja, ein kleiner Hinweis, dass hier was nicht ganz sauber läuft wäre schon nett (falls die NAS neben einem starken Magnetfeld steht ^^)

 

[mgutt]

Wenn du dein System in einem Raid fährst, geschieht die Selbstheilung on-the-fly beim Lesen. Prinzipiell wird der Hash-Abgleich ja bei JEDEM Lesevorgang durchgeführt. Man dürfte also (leider oder zum Glück) das niemals feststellen.

Das ist korrekt. Allerdings vergessen die meisten Privatanwender, dass die Parität von der CPU berechnet wird und die zusammen mit den Daten durch den RAM läuft, bevor sie auf der HDD landet. Wenn also eine Datei auf ein NAS geschrieben wird und das Bit kippt im RAM, dann wird zB eine korrekte Checksumme berechnet, aber mit den falschen Daten. Dies kann man nur mit ECC RAM verhindern, den aber die meisten Consumer-NAS gar nicht verbaut haben, so dass die Datei bereits kaputt ist, wenn sie auf die HDD geschrieben wird. Und ein Bit kippt immerhin auf 8% aller RAM-Module pro Jahr, wobei dies durch defekte Speicherbereiche oder kosmische Strahlung resultiert (wohlgemerkt in einem Rechenzentrum von Google, die ihren RAM erstmal "einbrennen", bevor sie ihn überhaupt nutzen und alle paar Jahre durchtauschen).

BTRFS schützt also nur, wenn die Datei bereits korrekt auf der HDD liegt und auf der HDD Bits kippen. Das ist aber sehr selten der Fall, weil HDDs selbst bereits einen ECC Algorithmus enthalten, womit alle Sektoren beim Lesen abgeglichen und repariert werden. Dank Reed-Solomon, kann die HDD dabei nicht nur ein gekipptes Bit reparieren, sondern mehrere und im Gegensatz zu einer XOR Parität, weiß die HDD Firmware auch immer, dass ein Bit gekippt ist.

Sollte es zu solchen kippenden Bits auf der HDD kommen, sieht man das über SMART bei der "Read Error Rate". Kam es zu solchen Fehlern, wird der betroffene Sektor als "Current Pending Sector" markiert. Und sollte sich beim nächsten Scan durch die HDD Firmware herausstellen, dass dieser Sektor defekt ist, wird er neu zugeordnet, was man beim "Reallocated Sector Count" sehen kann.

Bis hier hin hat die BTRFS Selbstheilung nicht geholfen, denn die HDD hat durchgehend die korrekten Daten zurückgeliefert.

Ist die Selbstheilung nun also Schlangenöl? Nein, denn es kann ja sein, dass ein Sektor komplett kaputt geht oder so viele Bits gekippt sind, dass die HDD Firmware, sie nicht mehr reparieren kann. Dann kommt es meist zu einem "Uncorrectable Sector". Jetzt kann BTRFS seinen Job machen und die kaputten Daten wiederherstellen.

Aber wie gesagt nützt das nichts, wenn man nicht sicherstellen kann, dass die geschriebenen Daten korrekt sind. Und das gilt natürlich auch immer dann, wenn man neue Platten einbaut und dadurch ALLE Daten ausgelesen und neu geschrieben werden. Ein RAM Modul ohne ECC mit defekten Speicherbereichen kann einem da schon einiges zerlegen und keiner merkt es.

Man sollte sich also bewusst sein, dass die BTRFS Selbstheilung nur einen Teil des großen Ganzen absichert. ECC RAM ist der Gurt im Auto und BTRFS der Airbag.

 

[mgutt]

BTRFS kann kein Raid5/6

Das ist falsch. Solange man die Metadaten im RAID1 abspeichert und die Daten im RAID5/6, passiert nichts. Steht auch so im Wiki:

It should not be used for metadata. For data, it should be safe as long as a scrub is run immediately after any unclean shutdown.

Dadurch geht natürlich mehr Speicherplatz verloren, aber Metadaten belegen nur wenige Prozent, also was soll's. Beispiel:

btrfs fi df .
Data, RAID5: total=9.83TiB, used=7.68TiB
System, RAID1: total=32.00MiB, used=704.00KiB
Metadata, RAID1: total=12.00GiB, used=8.61GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

Synology hat dagegen so viel ich weiß BTRFS auf einem mdadm Software-RAID liegen. Die Metadaten sind dabei "DUP", also ähnlich wie RAID1:

Data,single: Size:5.59TiB, Used:5.41TiB
   /dev/vg1/volume_1       5.59TiB

Metadata,single: Size:8.00MiB, Used:0.00B
   /dev/vg1/volume_1       8.00MiB

Metadata,DUP: Size:10.50GiB, Used:9.19GiB
   /dev/vg1/volume_1      21.00GiB

System,single: Size:4.00MiB, Used:0.00B
   /dev/vg1/volume_1       4.00MiB

System,DUP: Size:8.00MiB, Used:112.00KiB
   /dev/vg1/volume_1      16.00MiB

Was mich wundert, dass die Daten auf "single" stehen. Ich dachte eigentlich, das die Selbstheilung gar nicht in diesem Modus funktioniert?!

EDIT: Hatte ich richtig in Erinnerung, single bietet keine Selbstheilung. DUP schon, aber mit der Checksumme aus den Metadaten, kann man doch keine Datei reparieren?!

EDIT2: Moment. Synology sagt ja auch gar nicht, dass es eine Selbstheilung bei BTRFS gäbe, sondern nur ordnerbasiert. Aus dem Grund schließt Synology auch "VDSM oder VMM" explizit aus. Das hat also gar nichts mit BTRFS zu tun. Wusste ich auch noch nicht.

 

[peterhoffmann]

Andere Frage:
Wie oft habt ihr korrupte Dateien?
Ich selber hatte (mindestens) die letzten 10 Jahre keine korrupte Datei.

 

[H3llF15H]

Wie oft habt ihr korrupte Dateien?

Bis dato gar nicht. Aber zugegebenermaßen speichere ich immer mehr wichtige Daten und da lasse ich es nicht drauf ankommen.

 

[Heidi]

Wie oft habt ihr korrupte Dateien?

Ich kannte das von früher schon. Da hat man jpeg geöffnet und die waren unten abgeschnitten oder teilweise defekt.

So wie diese wiki-foto


Bei der immensen Fülle von Dateien, die man heutzutage auch als Privatanwender ansammelt fällt es oft garnicht auf. Bspw habe ich noch meine Handy-Rechnungen von vor 10 Jahren digital rumliegen. Kann ich jede dieser pdf noch öffnen? k.a.

Also ich bezweifle, dass auch du deine Dateien alle (die früher auf ext4 oder NTFS lagen) auf Korrektheit überprüft hast. Es sei denn du machst regelmäßig Hash-Checks. Da gibts wohl Programme, die das machen und dann die Hash-Summen abspeichern. Abseits vom FS.

Also die Frage ist eher weniger "wie oft habt ihr" sondern mehr: "Seit ihr mal auf eine dieser korrupten Dateien gestoßen, die sich in eurem System verbergen?"

Wenn man mal grob annimmt, dass man 500.000MB Private Daten hat und mit Fotos, Musik und ettlichen kleinen word-pdf-txt dokumenten die Dateien im Schnitt 1MB groß sind, dann sind das 500.000 Dateien. Wieviele davon "nutzt" man denn regelmäßig, und wieviele davon liegen nur rum. (Zugegeben, dann wäre es (abgesehen von alten Fotos) nicht arg schlimm wenn mal eine File hopps geht).

 

[peterhoffmann]

Bis dato gar nicht.

Du suchst also eine Lösung für ein Problem, welches gar nicht vorhanden ist.
ext4 z.B. ist gibt es seit 13 Jahren, der Urschleim ist von 1992 (ext), sprich die Entwicklung hatte 29 Jahre Zeit (ext>ext2>ext3>ext4).
Bei BTRFS sieht es schon anders aus. Da bastelt man seit 14 Jahren rum und hat immer noch Probleme.

Ich kannte das von früher schon

Früher... vor Jahrzehnten hatte ich das auch schon mal. Das war noch zu Zeiten von Disketten. Als die HDD-Zeit kam wurde das immer weniger bis gar nicht mehr.

jpeg geöffnet und die waren unten abgeschnitten

Ja, ist mir bekannt. Das war entweder zu Urzeiten oder die Fotos lagen auf einer Speicherkarte (z.B. SD-Karte). Das kam aber weniger von Problemen auf dem Datenträger, sondern das man z.B. den Speichervorgang vom Foto durch das harte Ausschalten der Digitalkamera unterbrochen hat. Dann war das Foto unten rum nicht vollständig.

Wenn man mal grob annimmt

Egal wie viel Dateien man hat, die Wahrscheinlichkeit ist da gnadenlos, sprich wenn es korrupte Dateien gibt, würde man irgendwann auch darauf mal stoßen.
Die Wahrscheinlichkeit ist nicht nur durch die Anzahl der zu öffnenden Dateien und die Zeit hoch, sondern wird dadurch noch verstärkt, dass u.a. je nach OS und Einstellung Vorschaubilder für jeden File generiert werden bzw. man das z.B. durch Thumbnailfunktionen in Programmen nutzt (z.B. Irfanview, Photoshop, Lightroom, usw.).

 

[H3llF15H]

Du suchst also eine Lösung für ein Problem, welches gar nicht vorhanden ist.

Nein, ich suche eine Lösung zur Prävention. Das Problem will ich nicht haben.

 

[peterhoffmann]

Das Problem will ich nicht haben.

Daher der Hinweis: Das Problem ist nicht vorhanden. Du holst dir eher mit BTRFS Probleme rein.

 

[H3llF15H]

@peterhoffmann
Nur wenn ich das Problem habe, ist es zu spät - und das will ich einfach vermeiden. Möglicherweise müsstest Du mich nochmal dort abholen, um zu verstehen, wo Btrfs zum Problem werden kann. Danke

 

[peterhoffmann]

Da musst du dich einlesen => https://www.google.com/search?q=BTRFS Probleme
Threads dazu gibt es genug.

Nicht falsch verstehen, ich will dir das BTRFS nicht madig machen. Wenn es bei dir passt, alles super.
Nur der Grund, dass man es wegen der Selbstheilung haben will, passt halt nicht. Das halte ich für einen Schlangenöl-Argument.

Bei wichtigen Dateien (nenne ich bei mir Kerndaten) nutze ich lieber eine mehrfache Sicherung in verschiedenen Zeitabständen (täglich, wöchentlich, monatlich, jährlich). Meine Kerndaten sind in der Regel Dokumente und private Fotos. Das macht bei mir nur wenige Gigabyte aus. Da kann ich es mir leisten diese in etlichen Zeitversionen, teilweise auf verschiedenen Geräten (offline/online/extern) vorrätig zu halten.

 

[Heidi]

Dies kann man nur mit ECC RAM verhindern

Donnerwetter. Man lernt doch ständig was dazu!

Ich dachte immer der ECC-RAM sorgt nur dafür, dass die hohe Taktungsgeschwindigkeit des RAM beibehalten werden kann. Wenn der RAM zu schnell taktet, wird das analoge Signal immer undeutlicher und eine interpretation (ob 1 oder 0 ankommt) wird schwer. Wenn nicht mehr verständliches zurückkommt, taktet der Prozessor nur noch halb so schnell (oder in welchen Schritten die Clock abstufen kann).

Aber deine Ausführung macht schon Sinn.

Dann muss ich hier sagen, habe dahingehend noch keine (negativen) Erfahrungen gemacht... Aber der Syno-RAM ist schweineteuer. 16GB für meine 1819+ lägen aktuell im noname bei 170 €.

 

[RichardB]

Nur der Grund, dass man es wegen der Selbstheilung haben will, passt halt nicht.

Auf den NASen ist mir bisher nichts aufgefallen, das sich selbst geheilt hätte (andererseits wäre es mir ja nicht aufgefallen).
Aber wie @Heidi geschrieben hat, ist es auf PCs schon hin und wieder vorgekommen, dass eine Anwendung den Dienst mit „Datei ist beschädigt und kann nicht geöffnet werden“ quittiert hat. Das betraf interessanterweise vor allem PowerPoint- und *.pdf- Dateien. Und Jahrzehnte ist das auch nicht her und die Dateien lagen auf HDDs.

Die „Selbstheilung“ ist zwar fein, der Hauptgrund für btrfs bei uns sind die Anwendungen, die nur mit btrfs laufen.