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

[Andy14]

Ok, es wird etwas off Topic, aber das Gleichheitszeichen zwischen MariaDB und MySQL könnte falsch verstanden werden. Es ist zwar eine Datenbank die aus MySQL hervorging aber insbesondere ab Version 10 nicht mehr 100% kompatibel ist.

 

[SynKlaus]

Eine Zeit lang schien es so, doch mittlerweile bin ich mir da nicht mehr so sicher. Mit auch weil Red Hat im August 17 ankündigte, langfristig(!) die Unterstützung von Btrfs in RHEL einzustellen. LINK Ferner halte ich BTRFS eher als ein FS das sich für dicke Workstation, und GamerPC gut eignet, hingegen für Datenspeicher und Datenbanken eher schlecht geeignet ist.

Das hätte ich jetzt genau andersherum gesagt. BTRFS ist meiner Meinung nach eher dort angebracht, wo es um Datenintegrität geht und weniger dort, wo es auf das letzte bisschen Performance ankommt.
Für mich persönlich ist die Datenintegrität wichtiger - Ich kann mit BTRFS jederzeit überprüfen, ob alle meine Daten intakt sind. Bei EXT4 lässt sich ein umgekipptes Bit nicht erkennen - Zumindest nicht durch das Filesystem. Das ist halt der Vorteil, den die Prüfsummen von BTRFS bieten - Natürlich müssen die erst berechnet werden und kosten so ein klein wenig Performance. Ich lese und schreibe jedoch auch mit über 100MB/s von meiner DS916+ und so ist eher das Netzwerk hier der Performance-Killer. Warum es bei manchen Probleme beim Schreiben Ihrer TV-Aufnahmen gibt, bleibt mir ein Rätsel.
Außerdem möchte ich nur ungern auf die Snapshots verzichten, mit deren Hilfe ich eine stündliche Momentaufnahme meiner aktuellen Arbeit realisiere, ohne dass ich was davon merke und ohne das dadurch groß Platz verschwendet wird.
Den Einwand mit der Datenbank-Engine sehe ich als berechtigt - Bloß, wenn ich wirklich eine schnelle DB brauche, lasse ich diese sowieso nicht auf der DS laufen, sondern auf einer dicken Workstation inkl. schneller SSD, viel Arbeitsspeicher usw.

Grüße.

 

[Nomad]

Ganz verstehen wohin die Reise geht tue ich auch nicht.

Wenn ich mir die Featureliste ansehe scheint es auch ein Versuch zu sein die zugegebenermaßen etwas sperrigen Techniken zusammenzufassen entgegen der *nix Philosopie, ein Tool, eine Aufgabe? Kein Wunder, dass die Entwicklung sich hinzieht bei der Funktionsfülle.

Noch vor einigen Jahren hätte ich gedacht, wir landen irgendwann bei Btrfs aber mittlerweile bin ich mir da nicht mehr so sicher. Nutzt außer Synology noch jemand Btrfs? Suse? Hätten sie genug Masse, um den Erfolg von Btrfs zu garantieren?

 

[SynKlaus]

Es gibt noch genügend andere vielversprechende FS, welche wohl die Zukunft sind und welche aber ähnliche Features wie BTRFS beherrschen. Das hat aber meiner Meinung nach nichts damit zu tun, für was man sich jetzt entscheidet - Sowohl BTRFS, als auch EXT4 werden irgendwann verschwinden - Aber auch nicht morgen.

Grüße.

 

[Bordi]

@SynKlaus: Da hast du es auf den Punkt gebracht. Die Snapshots, die lokale Performance, die Prüfsummen, der Einwand mit der Datenbank-Engine und das was man nicht durch Netz kriegt sprechen eindeutig dafür das man Btrfs an einer Workstation einsetzt. Da ist wo man die lokale Performance und Snapshots gut brauchen kann, lokal kurz gesichert ohne das Netz das behindert. Da ist es auch egal wen das FS nicht besonders gut mit RAID oder Datenbanken umgehen kann. Ganz anders bei einem Server, da ist Stabilität und der Umgang mit RAID und Datenbanken oberstes gebot. Nun Btrfs ist im Moment einigermaßen stabil, das bedeutet jedoch nicht das es für einen Server geeignet ist. Ein Server-FS sollte so stabil wie möglich sein. Es ist ein altes Rezept und wurde schon bei der Mondfähre angewandt: Um so viel Stabilität wie möglich zu erreichen muss das Objekt man auf eine Minimum reduzieren. Je weniger involvierte desto besser.

Bei Btrfs ist das genau anders rum, zwar sind Sicherheitselemente verbaut, jedoch auch viel anderes. Wem das was sagt: Mich erinnert Btrfs an einen Schwimmenden & Senkrechtsstartenden Pionierpanzer aus Karbon und Aluminium, der für die Elektronische Kriegführung konzipiert wurde, und ihn Lawinengebieten eingesetzt werden soll.

 

[Nomad]

Früher schrieben große Datenbanken direkt auf die Platte als Raw Device ohne das Filesystem des OS. Ist das jetzt aus der Mode gekommen?

 

[Scallywag]

Da ist es auch egal wen das FS nicht besonders gut mit RAID oder Datenbanken umgehen kann..

Wieso, kann BTRFS nicht gut mit RAID umgehen? Grade RAID bringt für BTRFS doch weitere Vorteile, da man bei einem gekippten Bit auf einer der Platten doch die richtige Datei anhand der Checksumme sofort erkennen kann.
Ich überlege auch eine DS218+ wegen BTRFS anzuschaffen, aber dann eben auch mit RAID-1 um eine noch höhere Ausfallsicherheit zu haben. Backup dann auf einer anderen DS.

 

[tproko]

Btrfs schreibt selbst, dass es auf OS Ebene nur für Raid1 kompatibel ist, aber nicht für Raid 5.

Das hat aber nichts damit zu tun, dass Synology mit Hilfe von mdadm ein Raid über dem OS aufbaut.
Und so Feature wie Selbstheilung sind dann denkbar und auch geplant bzw. von dsm umgesetzt.

 

[mgutt]

Ich habe noch ein Argument für BTRFS gefunden:
https://www.synology.com/de-de/know...rageManager/volume_filesystem_defragmentation

Die Dateisystem-Defragmentierung kann nur auf Volumes im Btrfs-Dateisystem durchgeführt werden.

 

[ElaCorp]

Hallo,

ich hab gerade die neue 920+ hier und möchte ein RAID5 einrichten.

In der Synology Hilfe wird erklärt, wann man Btrfs und wann man ext4 einsetzen soll. Leider brauch ich beide Bereiche.
Ich benötige sowohl iSCSI um auf einem Windows Rechner eine ausgelagerte Festplatte zu nutzen. Und ich habe 5 LiveKameras die die Surveillance Station verwenden.

Was empfehlt ihr mir? Was soll ich verwenden?

Laut den letzten 3 Seiten, soll man definitiv privat zuhause eher zu Btrfs greifen. Nur selten, zb bei 10GBit Leitungen lohtn sich etwas ext4 mehr.
Ist das noch aktuell?

 

[synfor]

Für die Surveillance Station ist ext4 wohl besser. Auf jeden Fall solltest du für den Ordner, in dem die Surveillance Station die Video ablegt bei BTRFS die Checksumme für die Datenintegrität nicht aktivieren. Bei der Einrichtung des Speicherpools am Anfang flexibel oder so ähnlich wählen, damit du einen Speicherpool bekommst, der mehrere Volumen unterstützt.

 

[Mettigel]

Hallo zusammen,
ich habe das gleiche Problem wie ElaCorp. Ich habe mir die DS220+ geholt und will meine DS215j ersetzen. Jetzt schwanke ich zwischen ext4 und btrfs.
Ich will SHR1 und nutze folgende Pakete:
- Surveillance Station
- Photo Station
- Audio Station
- Cloud Station
- MariaDB 10
- PHP
- phpMyAdmin

Gewünscht ist ein Volume über die gesamte Festplattengröße.
Ich nutze nur Windows-PCs und Android-Geräte.
Ich mache ein wöchentliches Backup auf eine alte NAS, zus. gelegentlich auf externe Festplatte (ich könnte das Backup auf der NAS versionieren, dann umgehe ich die Snapshots von btrfs?!?!
Kann man im Fehlerfall btrfs-Platten auslesen?

btrfs wollte ich aufgrund der Snapshot-Funktion. Aber wenn die DS dadurch (wegen der SS) ausgebremst wird, dann kann ich auch mit ext4 leben.

Falls ich bei ext4 bleibe: Würdet ihr die neue NAS auf jeden Fall neu aufsetzen oder von der alten DS215j migrieren? Soweit mir bekannt ist die Volumegröße der DS215j auf 16TB beschränkt, das sollte aber für die nächsten Jahre kein Problem sein. Bis ich diese Grenze überschreite hat die neue DS ausgedient.

 

[Synchrotron]

Da würde ich mir erst einmal einen anderen Gedanken machen: Der permanente Datenstrom aus der Videoüberwachung mischt sich mit den Daten aus der anderen Nutzung. Das tut nicht gut ... es entsteht ein „Schweizer Käse“ aus Datenblöcken, weil die Videoblöcke zyklisch gelöscht werden, die anderen nicht.

Für den Anwendungsfall würde ich überlegen, die beiden Platten jeweils als eigenes Volume aufzusetzen, Basic. Videostream auf die eine, den Rest auf die andere, ordentliches Backup sicherstellen. Es gibt spezielle Platten für Surveillance-Nutzung, wenn man das noch toppen will.

Oder die neue DS als Arbeitsgerät aufsetzen, die Videoüberwachung auf die alte laufen lassen.

Demgegenüber ist die ext4 / BTRFS - Diskussion in meinen Augen nachrangig.

 

[ElaCorp]

Ich hab mich für EXT4 entschieden und alles läuft sehr gut.

 

[mgutt]

btrfs wollte ich aufgrund der Snapshot-Funktion. Aber wenn die DS dadurch (wegen der SS) ausgebremst wird, dann kann ich auch mit ext4 leben.

Hier wird erklärt was BTRFS alles macht:
https://www.synology.com/de-de/know...the_Btrfs_file_system_on_Surveillance_Station

Um die Genauigkeit und den Schutz von Daten zu gewährleisten, unterstützt das Btrfs-Dateisystem anders als das RAID-System zusätzliche Datenschutz- und Sicherungslösungen. Nachfolgend finden Sie einige der wichtigsten Funktionen:

• Zwei Kopien von Metadaten: Metadaten enthalten wichtige Informationen von Speichersystemen, wie z. B. Ordnerstrukturen, Dateinamen, Zugriffsrechte sowie den Speicherort jeder Datei. Btrfs speichert zwei Kopien von Metadaten und ermöglicht so die Wiederherstellung der Daten, wenn eine der Kopien beschädigt ist.
• Btrfs-Datei-Selbstreparatur: Btrfs stellt Prüfsummen für Benutzerdaten und Metadaten bereit und verifiziert die Prüfsummen bei jedem Lesevorgang. Sobald eine Nichtübereinstimmung erkannt wird (stille Datenkorruption), kann das Btrfs-Dateisystem automatisch beschädigte Dateien mit gespiegelten Metadaten erkennen und defekte Daten mit dem unterstützten RAID-Volume wiederherstellen.
• Schnappschüsse und Datenschutz: Das Btrfs-Dateisystem basiert auf der „Copy-on-Write“-Architektur (Kopieren-nach-Schreiben) und ermöglicht Benutzern, eine zeitpunktbezogene Kopie (Point-in-Time) eines gesamten freigegebenen Ordners für Aufzeichnungs- oder Sicherungszwecke anzufertigen.

Das alles passiert bei ext4 nicht, weshalb BTRFS eine sehr hohe "Write Amplification" besitzt, die auf die Performance drückt.

Ich mache ein wöchentliches Backup auf eine alte NAS, zus. gelegentlich auf externe Festplatte (ich könnte das Backup auf der NAS versionieren, dann umgehe ich die Snapshots von btrfs?!?!
Kann man im Fehlerfall btrfs-Platten auslesen?

Ein Snapshot ist so gesehen kein Backup. Ein Snapshot verlinkt einfach nur die bereits existierenden Datenblöcke vom Zeitpunkt X noch einmal auf dem selben Volume. Und Dateikopien auf dem selben Volume sind zumindest für mich kein Backup.

Dazu kommt, dass Snapshots die Daten fragmentieren. Nehmen wir zB an, dass man eine Datei hat am Anfang der HDD auf dem Platter hat, dann einen Snapshot von dieser erstellt und schlussendlich 1 Bit von dieser Datei ändert. Dieses Bit landet dann am Ende vom HDD Platter. Wird diese Datei nun gelesen, muss der Lesekopf den Teil vom Anfang des Platters und den vom Endes des Platters lesen. Bekanntlich verursacht das eine Latenz. Aus dem Grund sollte man BTRFS Volumes auch regelmäßig defragmentieren.

Dann glaube ich aber auch, dass sehr viele Leute Snapshots völlig falsch verwenden. Nehmen wir an, dass du eine virtuelle Maschine hast und die macht gerade ein Update und du erstellst von dieser nun einen Snapshot. Was hast du nun? Eine korrupte Maschine, denn damit sie laufen kann, hätte das Update erst mal fertiggestellt un die VM heruntergefahren werden müssen (deshalb enthalten von VMWare erstellte Snapshots auch den RAM). Was bei einer VM vielleicht noch offensichtlich erscheint, beachten viele aber auch nicht bei den normalen Freigaben. Denn exakt das selbe passiert ja, wenn UserA was auf eine SMB Freigabe schreibt, während das Snapshot erstellt wird. Erneut haben wir korrupte Daten. Man müsste also eigentlich alle Dienste beenden, die auf die zu sichernden Daten zugreifen, dann den RAM leeren und erst dann kann man ein Snapshot erstellen.

Und dann glaube ich, dass nur wenigen wissen, wie man eigentlich ein externes Backup von einem Snapshot macht. Das geht bei Syno nämlich nur, wenn man zwei Synos hat und das Paket "Snapshot Replication" nutzt. Will man zB auf USB ein Snapshot sichern, bräuchte man dafür sowas wie Btrbk, aber das scheint hier niemand zu nutzen, da man es über die Suche nicht findet. Daher finde ich das schon erstaunlich, wenn Privatpersonen mit Snapshots "spielen".

Lange Rede kurzer Sinn. Wenn man keine VM Images hat, kein Active Backup for Business oder Snapshot Replication nutzt, kann man getrost auf BTRFS verzichten oder ich würde sogar sagen, sollte man darauf verzichten.

Leider kann man ja von Haus aus kein simples dateibasiertes inkrementelles Backup bei Synology machen. Also bleibt nur Hyper Backup. Ich mag diese ganzen ZIP-Archive aber nicht, weshalb ich stattdessen rsync dafür nutze. Hier ein Auszug aus meinem Script:

    # obtain most recent backup
    last_backup=$(ls -t "${backup_path}" | head -n1)
    # create incremental backup
    if [[ -n "${last_backup}" ]]; then
        echo "Create incremental backup ${new_backup} by using last backup ${last_backup}"
        rsync -av --stats --delete --link-dest="${backup_path}/${last_backup}" "${source_path}" "${backup_path}/.${new_backup}"
    else
        echo "Create full backup ${new_backup}"
        # create very first backup
        rsync -av --stats "${source_path}" "${backup_path}/.${new_backup}"
    fi

rsyncs "--link-dest" ist die "Magie", die inkrementelle Backups mit simplen Hardlinks ermöglicht. Und ich finde das sogar viel besser als inkrementelle Snapshots, da ich jedes beliebige Backup löschen kann, da keines auf das andere aufbaut. Jedes Backup ist also ein Vollbackup, aber trotzdem inkrementell. Klingt komisch, ist aber so. ^^

 

[Mettigel]

Danke für die schnellen Rückmeldungen.

@Synchrotron du hast sicher Recht, danke für deine Überlegungen. Aber die SS läuft auf dieser NAS seit min. 2017 mit diesen Platten (WD red 44000h und Seagate Desktop 50000h im SHR). Ich möchte aus ökologischer Sicht keine dritte NAS, welche ständig am Netz hängt. Bisher läuft es ohne Probleme, Backups sind vorhanden. Basic will ich nicht, weil ich da schon mal auf die Nase gefallen bin. Hat mich tierisch genervt, bis alles wieder wie gewohnt lief, trotz Backup. Bisher habe ich eine 50GB-Rotation je Kamera drin, die könnte ich hochschrauben. Dann werden die Blöcke weniger oft überschrieben.

Ich glaube, ich nehme auch ext4. Würdet ihr neu aufsetzen oder migrieren? Ich könnte die Platten mit den Backup-Platten rotieren. Also die bisherigen NAS-Platten als Backup nutzen und die Offline-Backup-Platten ins NAS packen, diese sollten erst wenige tausend Betriebsstunden haben. Alternativ eine Platte migrieren, SHR mit einer Backup-Platte migrieren, dann erst Platte gegen Backup-Platte tauschen. Sollte was schief gehen habe ich immer noch die Platte in der DS215j und das Backup auf der DS212...


Also:
- 1. bisherige Platten migrieren oder
- 2. nur eine Platte migrieren und dann mit Backup-Platten rotieren (2 x Rebuild)
- 3. neu mit jetzigen NAS-Platten aufsetzen
- 4. neu mit Backup-Platten aufsetzen (tendiere zu dieser Variante, alte NAS bleibt in Betrieb bis neue NAS läuft, zweites Backup vorhanden, falls Murphy zuschlägt)

EDIT:
Danke auch an @mgutt . Bleibe also beim ext4. Eigentlich habe ich nur eine Datei, von der ich gerne auf alte Versionen zugreifen möchte. Da mache ich bisher mit der Cloud Station und deren Versionierung, wenn das nicht reicht, dann eben über die Backups.

 

[Synchrotron]

Deine Entscheidung - nur dass hier kein Thread auftaucht wie „Leistungsprobleme“ oder „Festplatte frühzeitig defekt“.

Zum Dateisystem: ext4 ist von seiner Herkunft ein Desktop-Dateisystem, BTRFS vom Konzept her ein Server-Dateisystem. Je ähnlicher deine Verwendung einem Serverbetrieb ist, um so mehr spricht für BTRFS, ansonsten ist auch ext4 eine gute Wahl.

 

[Mettigel]

Laut der Homepage von Synology kann man von einer j nicht auf eine + migrieren. Ich habe einfach mal die Festplatte eingesteckt und er zeigt mir folgendes Fenster an...


synology.de:

 

[peterhoffmann]

Kann man im Fehlerfall btrfs-Platten auslesen?

Hier versucht es ein User schon etwas länger und kommt (bisher) nicht zum Ziel:
Link => https://www.synology-forum.de/threads/btrfs-volume-am-pc-auslesen.109614/

j nicht auf eine + migrieren

Das klappt. Ich nehme aber an, dass Synology das in der Tabelle nicht angibt, weil sie den Support dafür nicht leisten wollen.

 

[Mettigel]

Ich vermute, weil bei der j die Volumengröße auf 16TB beschränkt ist und bei den größeren könnte man auf 108TB gehen, nach der Migration bleibt die maximale Volumengröße aber bei 16TB.
Bei einer 2Bay mit Raid1 reicht 16TB bei mir noch sehr sehr lange.