Dateisystemwechsel von NTFS zu BTRFS oder EXT4 oder NTFS

[zcomputerbasez]

Also Platte 1 prüfen lassen, wenn Fehler gefunden Wird Platte 2 mounten und die besagten Dateien von Platte 2 auf Platte 1 händisch rüber kopieren?

 

[Banned]

Genau

Zur Sicherheit aber besser Platte 2 vorher auch scrubben (sofern das nicht in der jüngeren Vergangenheit geschehen ist), um nicht u.U. defekte Daten mit defekten Daten zu ersetzen.

 

[gea]

Das aufkommende moderne Universaldateisystem ist OpenZFS.
Kann mehr als btrfs und viel mehr als ntfs oder ext4. * Fat * ist dagegen ein Relikt der Steinzeit.

Aktueller Stand OpenZFS
Free-BSD: stabil
Illumos: stabil
Linux: stabil
OSX: released
Windows: release candidate, schon sehr brauchbar

Bei einzelnen USB Platten mit ZFS nur darauf achten dass der Pool darauf vor dem abstecken exportiert wird, sonst muss man neu booten um wieder Zugriff auf USB zu haben.

Mit ZFS copies=2 kann man auch auf einzelnen Platten Schutz vor defekten Sektoren aktivieren.

 

[JumpingCat]

Das aufkommende moderne Universaldateisystem ist OpenZFS.

Ist es das nicht seit 20 Jahren? seufz

 

[gea]

Vor 20 Jahren war ZFS Solaris only
Vor 15 Jahren kam Illumos dazu, dann Free-BSD, dann Linux

Aktuell auch OSX und Windows

 

[JumpingCat]

Für uns wurde ZFS-FUSE erst mit der Version 0.4 wirklich interessant, da diese Version verlässlichen Schreibzugriff bot. Die vorherige Version 0.3, die 2006 veröffentlicht wurde, war für uns nicht nutzbar, weil sie nur im Read-Only-Modus funktionierte, siehe z.B. https://www.golem.de/0612/49534.html.

 

[Banned]

@gea Klar, würde ZFS auch BTRFS deutlich vorziehen - benötigt halt mehr RAM (was hier wohl kein Problem sein dürfte) und wurde vom TE nicht als Option genannt (warum auch immer).

 

[zcomputerbasez]

Es wurde nicht genannt, da ich es leider auch noch nicht kenne. Auch wollte ich nicht x verschiede aufzählen, daher schrieb ich im ersten Beitrag „Was wäre in meinem Fall die sinnvollste Wahl: EXT4, BTRFS oder ein anderes Dateisystem?“

Der unpassende Betreff meines Threads liegt auch darin begründet, dass ich ursprünglich dort bereits mehr aufzählen wollte.

 

[gea]

Im Prinzip gibt es 3 Klassen von Dateisystemen

1. heutzutage nicht mehr zu empfehlen (* FAT *)
2. ganz brauchbar aber nicht Stand der Technik (ext4, ntfs, xfs)
3. Stand der Technik mit Copy on Write und Prüfsummen (Vorbild ist ZFS aber auch APFS, btrfs und ReFS)

Ergänzung (8. August 2025)

@gea Klar, würde ZFS auch BTRFS deutlich vorziehen - benötigt halt mehr RAM (was hier wohl kein Problem sein dürfte) und wurde vom TE nicht als Option genannt (warum auch immer).

Eigentlich ist es nicht ZFS das mehr RAM braucht, sondern es ist der Nutzer der die Nachteile von Copy on Write (Fragmentierung) und Prüfsummen (mehr Daten) insbesondere auf HD Pools klein halten will indem massives rambasiertes read/write caching benutzt wird. Lediglich Echtzeit-Dedup braucht massiv RAM aber das muss man nicht nutzen oder man nimmt fast-dedup in OpenZFS 2.3 das weniger RAM benötigt und man kann da den RAM Bedarf begrenzen.

ZFS nutzt auf Linux per default 50% RAM zum Cachen, Wert kann man ändern und ZFS gibt RAM frei wenn andere Anwendungen den benötigen. Ram Caching machen heute aber alle auch ohne ZFS. Man hat ja RAM gekauft um was sinnvolles damit zu machen.

 

[Banned]

EXT4, BTRFS oder ein anderes Dateisystem?“

Ah, okay, ist mir entfallen. Dann würde ich zu ZFS raten.

 

[recu]

+1 für ExFAT.

Dein +1 gilt nur der Eigenschaft als Dateisystem, um Daten zwischen verschiedenen Betriebssystemplattformen physisch zu tauschen...

ExFAT ist auch schnell und „ausfallsicher“ wie EXT4? Mir fällt auch noch XFS ein. ExFAT hat bei mir so eine negativen Touch. Ich hatte mal einen Samsung-USB-Stick 256GB mit ExFat den es sehr schnell zulegt hat.

Ich bin mir im Klaren, dass das vermutlich am „Stick“ lag, aber seit dem habe ich ExFAT in keiner guten Erinnerung.

Nein. ExFat ist wie ein VW Käfer mit Feststoffraketen, aber immer noch ohne Bremskraftverstärker und mit Trommelbremsen hinten.

Warum?
ExFat verwaltet die Sektoren in Clustern und nutzt die FAT (file allocation table) zum Nachschlagen, wo sich die Daten einer Datei befinden.
Hast Du eine Festplatte mit einer Sektorgröße von 512 Byte und wird ein Sektor der FAT unlesbar, dann fehlt schlimmstenfalls für 512 Byte / (4 Byte/Cluster) =128 Cluster die Information über den Folgecluster. Das bedeutet schlimmstenfalls 128 kaputte oder nur noch zum Teil auslesbare Dateien.

Bei NTFS z.B. wird diese Information zwar auch zentral in der MFT (master file table) gespeichert, aber typischerweise benötigt ein Eintrag in der MFT einen Datensatz à 1024 Byte. Wird dieser Eintrag unlesbar, verlierst Du schlimmstenfalls die Speicherorte der Cluster einer Datei, mehr nicht.
Die Clusterinformationen werden eben bei NTFS bei den Metadaten der jeweiligen Datei gespeichert und nicht in einem konzentrierten Pool, wie bei FAT-Systemen.

Die FAT ist das für Microsoft-Dateisysteme, was der Reaktorschacht für Star Wars ist: Ein Treffer, und es geht viel kaputt!

 

[Caramon2]

MountWalker: Danke für die klaren Worte zu ExFAT. Ich glaube ich tendiere zu XFS. EXT4 lasse ich lieber - irgendwie muss man sich ja entscheiden.

Hi, ich bin zufällig hierauf gestoßen und wollte noch ergänzen:

- exFAT ist praktisch ein minimal erweitertes FAT64, aber dafür wurde die FAT-Kopie gestrichen, wodurch es sogar noch unsicherer als das herkömmliche FAT(12/16/32) ist. - Nicht nur theoretisch: Das habe ich schon so oft erlebt, dass ich es gar nicht mehr nutzen. - Quasi das russische Roulette der Dateisysteme.

- ext4 ist noch 32-bit und damit genauso "zeitgemäß" wie NTFS.

- xfs ist meinen Erfahrungen nach nahezu unkapputtbar: kopiere z. B. einen Ordner mit vielen Unterverzeichnisse und kleineren Dateien auf einen USB-Stick und ziehe ihn währenddessen ab. - Nach dem wieder anschließen, repariert xfs sich beim ersten einhängen innerhalb eines Sekundenbruchteils selbst (kann man mit dmesg kontrollieren) und alles bis auf das gerade kopierte Unterverzeichnis ist noch da und in Ordnung.

- Bei btrfs hatte ich früher oft "incorrectable errors" (also Neuformatierung und Datensicherung wiederherstellen - deshalb habe ich es nicht auf der Homepartition genutzt, weil zu groß und auf den Sicherungsplatten natürlich erst recht nicht), aber zuletzt im Dez. 2024.

Wegen dessen zStd-Komprimierung nutze ich es inzwischen überall wo es möglich ist (aber ohne @-Kram und Snapshots: davon halte ich nichts) und überprüfe es regelmäßig mit btrfs scrub, aber trotz der viel umfasserenden Nutzung ist es nicht mehr zu Fehlern gekommen.

Übrigens formatiere ich btrfs mit den Optionen -O bgt -n 64k (großes "O": bgt ist kurz für block-group-tree), da beides bei Festplatten und SSDs deutliche Vorteile hat und ich keine Nachteile bemerken konnte.

 

[recu]

Hi, ich bin zufällig hierauf gestoßen und wollte noch ergänzen:

- exFAT ist praktisch ein minimal erweitertes FAT64, aber dafür wurde die FAT-Kopie gestrichen, wodurch es sogar noch unsicherer als das herkömmliche FAT(12/16/32) ist. - Nicht nur theoretisch: Das habe ich schon so oft erlebt, dass ich es gar nicht mehr nutzen. - Quasi das russische Roulette der Dateisysteme.

- ext4 ist noch 32-bit und damit genauso "zeitgemäß" wie NTFS.

Unsinn!
Seit Einführung im Jahre 2006 benutzt ext4 Blocknummern, die als 48-Bit-Zahlen gespeichert werden.

Wikipedia führt dazu aus:

[...ext4 benutzt 48 Bit große Blocknummern (ext3 hatte 32 Bit) und unterstützt so Partitionen oder Volumes, die bis zu 1 YiB groß sind...]

Quelle:
https://de.wikipedia.org/wiki/Ext4

Ergänzung (7. März 2026)

Wie gesagt, würde ich nicht empfehlen. Der Vorteil auch ohne RAID ist aber: Wenn du einen Scrub durchführst und es tritt ein Fehler auf, der nicht über den Sektor-ECC auf Firmware-Ebene der Festplatte korrigiert werden konnte oder dort nicht erkannt wurde, wohl aber über die Prüfsumme auf Dateisytemebene - dann kann man sich bei BTRFS anzeigen lassen, welche Dateien betroffen sind. Die werden zwar nicht automatisch angezeigt wie nach einem ZFS-Scrub, aber man kann die Informationen abrufen:
https://superuser.com/questions/858237/finding-files-with-btrfs-uncorrectable-errors (zweitletzter Beitrag)
https://wiki.archlinux.org/title/Identify_damaged_files#btrfs

Bei Dateisystemen ohne Prüfsummen auf Dateisystemebene bzw. bei einem einfachen RAID kann man hingegen nicht herausfinden, welche Dateien betroffen sind, da sich alles nur auf Firmware-Ebene abspielt, auf die man idR keinen derartigen Zugriff hat.

Nein. Die Zuordnung von Clustern zu Dateien findet auf der Dateisystemebene statt.
Auf der Firmware-Ebene z.B. bei einem RAID5 findet lediglich die Übersetzung einer Sektornummer eines von der Firmware suggerierten großen virtuellen Geräts in zwei Adressen statt, der Adresse wo die Daten dieses virtuellen Sektors physisch gespeichert sind und wo sich die Parity-Information befindet.

 

[Caramon2]

Seit Einführung im Jahre 2006 benutzt ext4 Blocknummern, die als 48-Bit-Zahlen gespeichert werden.

Danke. Das wusste ich nicht.

Das 32-bit war nur ein gutes Argument, da ich ext4 aufgrund schlechter Erfahrungen schon lange nicht mehr nutze: xfs war damals (vor ca. 10 Jahren) im direkten Vergleich sehr viel besser und ext4 macht für mich schon deshalb einen schlechten Eindruck, weil es nicht vollständig formatiert wird, sondern es nach dem ersten einhängen noch bis zu mehrere Minuten (je nach Größe) auf dem Laufwerk herum rödelt: s. manpage, irgendwas mit "lazy". - Deaktiviert man das, dauert formatieren sehr viel länger. Ich empfinde das als primitiv (das ist nur mein persönlicher Eindruck - ich will damit niemanden angreifen).

Bei Dateisystemen ohne Prüfsummen auf Dateisystemebene bzw. bei einem einfachen RAID kann man hingegen nicht herausfinden, welche Dateien betroffen sind, da sich alles nur auf Firmware-Ebene abspielt, auf die man idR keinen derartigen Zugriff hat.

Ich prüfe btrfs+xfs regelmäßig mit dem jeweiligen scrub-Befehl, aber gelegentlich (sozusagen als zweite Meinung) auch mit der "Holzhammermethode".

Die funktioniert mit jedem Dateisystem:

Um zu testen ob noch alles lesbar ist, kopiere ich alles vom jeweiligen Hauptverzeichnis aus rekursiv ins Nirvana:
sudo tar c .|pv -s$(sudo du -sb|cut -f1) > /dev/nullIch nutze dazu "tar", da ich sehr viel mit Hardlinks arbeite: "tar" erkennt das und kopiert die entsprechenden Dateien nur einmal.

Gerade erst gestern bei drei (verschlüsselten) Sicherungslaufwerken gemacht (2x 500 GB HD, 1x 2 TB SSD, alle wie hier beschrieben eingerichtet): Keine Fehler.

 

[andy_m4]

s. manpage, irgendwas mit "lazy"

lazy_itable_init
und ggf. noch lazy_journal_init
Manpage: mke2fs(8)

Deaktiviert man das, dauert formatieren sehr viel länger.

Wie oft formatierst Du, das deren Dauer ein echtes Problem ist? :-)

funktioniert mit jedem Dateisystem

Wobei ein einfaches dd vermutlich schneller ist, da einfach nur sequentiell gelesen werden muss und Du auch wirklich sicher alle Bereiche der Platte/Partition abdeckst:
dd if=/dev/sdXn of=/dev/null bs=4M iflag=direct status=progress

Die tar-Methode ist besser, wenn Du Fehler entdeckt hast und jetzt wissen willst, welche Dateien konkret betroffen sind.

 

[Caramon2]

Wie oft formatierst Du, das deren Dauer ein echtes Problem ist? :-)

Für mich wird das lazy formatieren genutzt, um gravierende Mängel (eben dass das formatieren so elend lange dauert) zu kaschieren: Wer weiß was durch solche Tricks noch alles kaschiert wird? - Mit so einer "Mogelpackung" will ich nichts zu tun haben, zumal es die negativen Eindrücke, die ich vorher schon hatte, sozusagen bestätigte. - Wie gesagt: Meine persönliche Meinung.

Andere mögen vielleicht xfs schlecht finden, weil man es nicht verkleinern kann. - Da die persönliche Datenmenge ja immer weiter abnimmt, natürlich ein sehr gewichtiger Grund.

Wobei ein einfaches dd vermutlich schneller ist, da einfach nur sequentiell gelesen werden muss und Du auch wirklich sicher alle Bereiche der Platte/Partition abdeckst:
dd if=/dev/sdXn of=/dev/null bs=4M iflag=direct status=progress

Damit überprüfst du das Laufwerk, aber nicht ob sich das Dateisystem mal wieder verschluckt hat und Dateien geschreddert wurden.

Weil ich das immer wieder bei btrfs hatte, hast du mir damals geholfen, die tar-Methode zu entwickeln. - Danke nochmal dafür.

 

[andy_m4]

Für mich wird das lazy formatieren genutzt, um gravierende Mängel

Das hat damit eher weniger zu tun.
Man möchte halt nur die Möglichkeit zur Verfügung stellen, das Dateisystem so früh wie möglich nutzbar zu machen ohne zwangsweise die vollständige Initialisierung abwarten zu müssen.

Wer weiß was durch solche Tricks noch alles kaschiert wird?

Naja. Gerade die ext-Dateisysteme dürfen unter Linux die mit am besten Überprüftesten überhaupt sein. Das da also irgendwelche Mängel kaschiert werden, erscheint mir eine wackelige Theorie. :-)

zumal es die negativen Eindrücke, die ich vorher schon hatte, sozusagen bestätigte

Also es gibt sicher Dinge die man an ext4 kritisieren kann.
Einiges davon ist auch historisch bedingt. Und man hat da auch selten mal wirklich aufgeräumt, weil es dem Projekt wichtig war, das immer und ohne Neuformatierung die Transition von einer Major-Version zur Nächsten hinkriegt.
Die Codebasis ist im Vergleich zu anderen Dateisystemen immer noch relativ klein.
Auch liegt ja ein Schwerpunkt darauf, auch bei schmaler Hardware und kleinen Datenträgern gut zu funktionieren. Und den Spagat sowohl da als auch auf größeren Platten gut zu funktionieren, kriegt ext4 ganz gut hin (wenngleich es nicht meine erste Wahl wäre).

Will sagen:
Für alles gibt es auch Gründe und es geht nicht darum den Nutzer zu ärgern und Ähnliches
Deshalb finde ich es unangemessen von "Tricks" und und "kaschieren" zu reden, weil das impliziert das hier irgendwie was in unlauterer Absicht gemacht wurde.

Damit überprüfst du das Laufwerk, aber nicht ob sich das Dateisystem mal wieder verschluckt hat und Dateien geschreddert wurden.

Richtig. Aber es ging ja um scrub und scrub führt auch ein Lesetest auf allen(!) Blöcken aus. Und den Part deckt der der tar-Test nicht ab, aber der dd-Test. Darum ging es (mir bei meiner Anmerkung).
(wobei das ZFS/btrfs-scrub ja noch besser ist, da es auch gegen eine Prüfsumme vergleicht; aber das wurde hier ja schon thematisiert)

Und da wollte ich auch gar nicht in ein entweder-oder rein, sondern in ein sowohl-als-auch

 

[Caramon2]

Naja. Gerade die ext-Dateisysteme dürfen unter Linux die mit am besten Überprüftesten überhaupt sein. Das da also irgendwelche Mängel kaschiert werden, erscheint mir eine wackelige Theorie. :-)

Wie gesagt: Das ist rein subjektiv. Mir kommt es so vor und ich sehe meine früheren Erfahrungen mit ext4 bestätigt: Passt.

Richtig. Aber es ging ja um scrub und scrub führt auch ein Lesetest auf allen(!) Blöcken aus.

Der von btrfs definitiv nicht: Bei einem frisch formatierten btrfs läuft das innerhalb eines Sekundenbruchteils durch. Sonst würde ich das ja nicht bei standardmäßig nach der Formatierung nutzen (s. in #34 verlinkten Beitrag). - Und der von xfs prüft auch nur die Dateien.

Anders als z. B. chkdsk /f /r, weshalb ich für ntfs und fat* die ausschließlich die tar-Methode nutze, wenn mich interessiert, ob alles noch lesbar ist.

Für eine komplette Laufwerksprüfung nutze ich gelegentlich den vollen SMART-Selbsttest.

 

[andy_m4]

Wie gesagt: Das ist rein subjektiv

Dein subjektiver Eindruck ist also, das die ext(2/3/4)-Entwickler gegenüber den Usern tricksen und kaschieren wollen? Spannend.

Bei einem frisch formatierten btrfs läuft das innerhalb eines Sekundenbruchteils durch.

Ich weiß nicht im Detail wie es bei btrfs ist, aber bei ZFS ist es so das ein Aufruf von
zpool scrub
sofort "durch" ist, weil das Scrubbing im Hintergrund ausgeführt wird (das kann man verhindern, wenn man zpool scrub -w aufruft; dann wartet er brav bis er durch ist).
Man kann den Fortschritt mit Hilfe von zpool status auch jederzeit beobachten.

Bei btrfs scheint es aber recht ähnlich zu sein.
Ein btrfs scrub start
startet ebenfalls einen Background-scrub (siehe dazu btrfs-scrub(8)).
Ein angehängtes -B hält es im Vordergrund.
btrfs scrub status gibt ein Status-Report.

 

[JumpingCat]

Der von btrfs definitiv nicht: Bei einem frisch formatierten btrfs läuft das innerhalb eines Sekundenbruchteils durch.

Na der von ZFS auch. Es wird data scrubbing auf den Device Tree gemacht, d.h. der gesamte Verzeichnisbaum wird geprüft ob der valide ist und alle dort referenzierten Daten lesbar sind.
Je mehr Daten du hast um so länger dauert das.