Ich bin Fan von BTRFS weil es gegenĂŒber ext4 ein paar (optionale) Vorteile hat, namentlich transparente Kompression mit zstd, Extent-basierte (manuelle) Deduplizierung, Subvolumes/Snapshots, und Copy-on-Write.
Dank der Kompression spare ich laut meinen eigenen Tests ungefÀhr 8% an Speicherplatz ein. Macht das Schreiben und Lesen auf schnellen (respektive sehr schnellen) SSDs etwas langsamer, aber spÀtestens bei meinen HDD-DatengrÀbern ist auch das transparent (die CPU kann schneller (de)komprimieren als die Platte schreiben/lesen).
So generell suche ich gern mal nach doppelten Dateien mit rmlint. Bei BTRFS kann ich noch einen Schritt weiter gehen: die Dateien sind da ja aufgeteilt in Extents, und mit Programmen wie duperemove kann ich auf dieser Ebene Dupletten suchen und löschen. Wenn zwei oder mehr Dateien dann identische Bereiche haben, werden diese nur einmal physisch gespeichert, und von jeder Datei referenziert.
Mit Subvolumes kann man in Sekunden eine Kopie eines anderen Subvolumes anlegen. Das wird gern benutzt fĂŒr Snapshots:
Copy-on-Write schreibt, wenn eine Datei geĂ€ndert wird, diese in einen neuen Bereich und Ă€ndert dann die Zuordnung/Verweise auf die Datei. So kann mitten beim Schreiben der Strom ausfallen, und man hat zumindest noch die alte Version. Das macht natĂŒrlich bei groĂen, viel editierten Dateien wie virtuellen Festplatten von virtuellen Maschinen wenig Sinn, weswegen man das fĂŒr einzelne Verzeichnisse deaktivieren kann, solange noch keine Dateien drin sind.
Was BTRFS leider (noch?) nicht nativ kann, ist VerschlĂŒsselung. Kann man aber leicht per LUKS/Veracrypt machen. Dann hat man quasi den physischen DatentrĂ€ger => VerschlĂŒsselungs-Ebene => Partition mit BTRFS => Subvolume(s) => Verzeichnisse und Dateien.