BTRFS - Ausgereift und sicher genug fuer Anfaenger bzw. Laien?

@zivilist
Die aller meisten Dokumentationen außerhalb von Mailinglisten und Manpages gehen halt überhaupt nicht darauf ein. Selbst wie wikis auf kernel.org sind da nicht all zu erleuchtend und Anleitungen von Dritten schreiben gefühlt alle voneinander ab und sind auf dem Stand von Anno dazumal.

Und der Vollständigkeit halber. Mdadm mit Journaling kam mit Kernel 4.4 Ende 2015
https://lwn.net/Articles/665299/
 
  • Gefällt mir
Reaktionen: Termy
Garmor schrieb:
Das hatten wir bestimmt schon mehrfach: auch wenn Timeshift sich so einstellen lässt, dass es wie ein Backuptool funktioniert, ist es eigentlich nicht dafür gedacht, sondern für Snapshots der Systemdateien.
Es wurde auf alle Faelle in meinem Umstiegsthread angesprochen :D Ich weiss aber nicht mehr von wem.
Timeshift verwendet aber bei EXT 4 rsyc, wenn ich es richtig verstanden habe.
Ja, keine echten snapshots, aber als Backup reicht es mir im Moment.

Alle Spiele die ich aktuell unter Steam spiele unterstuetzen Cloud Saves. Ansonsten ist von meinem Browserprofil abgesehen nichts da, was nicht zu ersetzen waere. Und das sichere ich regelmaessig.
 
Ranayna schrieb:
Es soll kaputtgehen wenn man es vollaufen laesst, dazu soll es sogar problematisch sein ueberhaupt zu ermitteln wie voll die Platte ist,
Mal so auf Deine PC-Ausstattung bezogen:
wenn die QVO SSD voll läuft, wirst Du es vermutlich schon vorher mit langsamen Schreiboperationen bemerken. Und wenn die Systempartition voll läuft, hast Du vermutlich auch unter Linux noch andere Probleme. Bei einem CoW Dateisystem mag das nicht so prickelnd sein wenn es nicht nur eine Datenpartition ist, auf die man einzig manuell kontrolliert schreibt.

Für die Größenermittlung gibt es BTRFS eigene Tools, die auch eines der Features berücksichitgen, das hier anscheinend den Leuten, die BTRFS nuzten, egal ist.

Ich nutze BTRFS auf meinem Backup-Rechner für die Datenplatten einzig um automatisiert BitRot zu erkennen (Prüfsummen). Kompression wäre auf dem Desktop u.U. noch eine schöne Option (müsste man mal vorher benchmarken). Die Ermittelung des freien Platzes wird dann endgültig zur groben Schätzung.

Ranayna schrieb:
Aber sind die Vorteile das Risiko wert?
Das musst Du für Dich selber abwägen. Persönlich habe ich bisher wenig Angst vor einem Stromausfall. Aber ich habe auch genauso wenig Angst vor einem Überspannungsschaden, einem Hausbrand oder sonstigen Dingen, die Leute mit klassisch definierten Backups in ihrer Risikoabschätzung meist extrem hoch bewerten.
 
zivilist schrieb:
Ist schon lange default bei professionellen NAS Systemen von Synology. In Semi-professionelle NAS hat es auch schon lange Einzug. Also ja würde es seit min 5 Jahren als stabil einschätzen.
Du vergisst hier zu erwähnen, dass da nur der Dateisystem-Part verwendet wird und Kompression sowie Scrubs.
Weder Verschlüsselung noch Raidfunktionalität von BTRFS wird hier verwendet weil instabil bzw. nicht vorhanden.
 
Ranayna schrieb:
Timeshift verwendet aber bei EXT 4 rsyc, wenn ich es richtig verstanden habe.
Timeshift kann auch mit btrfs weiterhin rsync nutzen wenn du das willst.
Genau wie Back in Time (meine Empfehlung fuer das Backup der nicht-system Daten) auch ^^
 
Btrfs kann man nehmen. Ich würde trotzdem ein ZFS vorziehen, da es ausgereifter ist und einige Features in Btrfs noch nicht funktionieren (wenn sie überhaupt jemals irgendwann funktionieren). Trotz allem hat Btrfs einen Reifegrad erreicht das man es durchaus verwenden kann.
Wenn Dir Dein System Btrfs anbietet dann würde ich es also so lassen. Hast Du beide Optionen (also ZFS und Btrfs), dann würde ich ZFS ins Auge fassen.
 
  • Gefällt mir
Reaktionen: Arc Angeling
guzzisti schrieb:
ZFS für die System und Home-Partition?
Ja klar. Macht ja nun wenig Sinn da künstlich wieder was aufzutrennen wenn man schon ein Dateisystem hat, was alle Anwendungsbereiche abdecken kann.
Wo ich ZFS einsetze habe ich stets nur ZFS und nicht noch irgendein anderes Dateisystem am laufen (mal abgesehen von dem FAT in der UEFI-Partition, sofern vorhanden).
 
  • Gefällt mir
Reaktionen: Arc Angeling
Drewkev schrieb:
Bei ZFS stört mich die Deduplication,
Dann benutze sie nicht. :-)
Man muss aber tatsächlich sagen die ist wirklich nicht besonders effizient implementiert was dazu führt, das Du vergleichsweise viel RAM brauchst.
Es gibt noch ein paar andere Sachen die in ZFS suboptimal sind, die man wohl aus heutiger Sicht anders lösen würde.
Ist halt immer die Frage, inwieweit das für einen relevant ist. Häufig ist da, wo es relevant ist (Rechenzentrum) RAM jetzt auch keine Mangelware. Und im heimischen NAS wird man Deduplication wohl eher weniger brauchen.
 
  • Gefällt mir
Reaktionen: snaxilian
andy_m4 schrieb:
Es gibt noch ein paar andere Sachen die in ZFS suboptimal sind,
Vor allem die Tatsache, dass es out-of-tree ist wenn man Linux nutzt :freak:
Grade wenn man eine RR Distro mit linux-latest nutzt kann es bei einem neuen Kernel immer mal ne weile dauern bis das Modul funktioniert - doof wenn man dann / auf ZFS hat und unbedacht updated :D
 
  • Gefällt mir
Reaktionen: guzzisti
Termy schrieb:
Vor allem die Tatsache, dass es out-of-tree ist wenn man Linux nutzt
Gut. Entweder nutzt man dann halt kein Linux oder eine Distribution die ZFS supportet.
Termy schrieb:
Grade wenn man eine RR Distro mit linux-latest nutzt kann es bei einem neuen Kernel immer mal ne weile dauern bis das Modul funktioniert - doof wenn man dann / auf ZFS hat und unbedacht updated
Wenn ich versehentlich update und irgendwas funktioniert nicht, dann gehe ich halt ein Schritt zurück.
 
  • Gefällt mir
Reaktionen: snaxilian
Man kann auch RR mit -latest und bleeding edge nutzen aber zwischen dem was man technisch kann und was sinnvoll ist, liegen Welten.
Für Server, die Anwendungen bereit stellen, v.a. stateless Anwendungen oder auch stateful wo die Daten 'woanders' liegen, da mag sowas laufen. Wenn du aber eine vierstellige Anzahl Server betreibst mit einer größeren dreistelligen Anzahl Anwendungen von denen manches Eigenentwicklungen sind und manches eingekaufte Software ist und manches dann auf Standardsoftware aus den Repos setzt, du aber nur mit einer kleinen zweistelligen Anzahl Admins das betreibst dann wirst du garantiert kein RR nutzen.

Also in einer perfekten Welt wo du von Beginn an streng mit TDD arbeitest und alles aber wirklich alles als Infrastructure as Code ansiehst und mit vernünftiger CI/CD arbeitest, da kann man sowas machen weil man eh alle paar Tage oder Wochen alles neu baust und jetzt geh mal in einen Konzern oder größere Firma die 20+ Jahre existiert und dann mach du da mal alles auf RR, vor allem die Storages und Fileserver. :freak:
 
  • Gefällt mir
Reaktionen: andy_m4
alles in ein File System zu stopfen wie bei BTRFS, laut Dokumentation und diversen Themen, erscheint mir unklug. siehe systemd Thematik.

Meine Rechner werden nur mehr mit lvm2 / luks / ext4 + tmpfs aufgesetzt.

Ich musste sogar Fehler in ext4 und reiserfs ausbessern. Ich habe keine Lust mehr auf Experimente wie reiserfs und ext3 und ext4. In einem Produktionssystem habe ich keine Lust, Zeit und Risikobereitschaft für Datenvernichtung.
 
  • Gefällt mir
Reaktionen: Kuristina
Du kannst ja auch mit btrfs mehrere Subvolumes haben, dann ist nicht alles in einem Filesystem. Alles in eins stopfen war noch nie sinnvoll bzw. es gab schon seit gefühlt 10+ Jahren best practices welche Verzeichnisse ggf. in einer eigenen Partition/Volume sein sollten je nach Anwendungsfall.
 
  • Gefällt mir
Reaktionen: andy_m4
_roman_ schrieb:
alles in ein File System zu stopfen wie bei BTRFS, laut Dokumentation und diversen Themen, erscheint mir unklug. siehe systemd Thematik.
Erklär mal, statt nur Andeutungen zu machen.

Drewkev schrieb:
Für mich ist es aber relevant, also nutze ich es auch. :-)
Alles gut. Das ist doch auch völlig in Ordnung. 👍
 
  • Gefällt mir
Reaktionen: snaxilian
Zurück
Oben