Dateisystemwechsel von NTFS zu BTRFS oder EXT4 oder NTFS

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?
 
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.
 
Zuletzt bearbeitet:
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.
 
Zuletzt bearbeitet:
Vor 20 Jahren war ZFS Solaris only
Vor 15 Jahren kam Illumos dazu, dann Free-BSD, dann Linux

Aktuell auch OSX und Windows
 
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.
 
@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).
 
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.
 
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 ()

Banned schrieb:
@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.
 
Zuletzt bearbeitet:
Metalveteran schrieb:

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

zcomputerbasez schrieb:
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!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Fusionator, nutrix, zcomputerbasez und eine weitere Person
Zurück
Oben