Na gut, das kann erfahrungsgemäß eine Woche dauern oder 2 Jahre bis das gefixt ist.
Wenn ihr sagt Ext4 wäre die Lösung, dann gut. Aber ich müsste mir ne neue 18 TB HDD kaufen, denn ich möchte meine alte Filmeplatte nicht mit Daten drauf von NTFS auf Ext4 konvertieren. Und das ist schon meine Backupplatte und ich traue solchen Konvertierungstools bei sowas nicht so recht. Der Lösung stehen also 400 € im Wege...
Ist ja nicht die eine Loesung die es gibt.
Das Du da das Problem mit dem unmounten analysiert hast waere es toll wenn das gefixt waere. Dafue muesste das aber zu LE reported werden. Das ist ein Teil der Loesung.
Ext4 zu verwenden ist unabhaengig davon ein anderer Teil der Loesung, solange es fuer NTFS keinen vernuenftigen fsck unter Linux gibt.
16TB USB sind deutlich guenstiger, 284 Euro.
btrfs z.b. hat Logging anstelle von Journaling. Und sollte deswegen beim schreiben sogar schneller sein. Allerdings war meine Erfahrung vor mehreren Jahren leider eher das das Filesystem bei ploetzlichem Stromverlust doch komplett kaputt war.
seit "vor mehreren Jahren" wurde aber auch heftiger an BTRFS geschraubt, wie an EXT4 auch ...
BTRFS hat COW (copy on write) und daher ist das filesystem *stets* in einem konsistenten Zustand, auch wenn ich im laufenden Betrieb den Stecker ziehe.
setze das seit einigen Monaten unter Fedora 38 (oder sogar schon 37 ?) ein; auch auf meinen BackupPlatten.
also ich würde, insbesondere bei unsauberen umounts (egal wieso) stets Btrfs ggü. ext4 vorziehen: bei hard power off fällt der fsck weg
und buildin RAID1 (mirror) gibts auch.
ein ~Handycap~ bleibt allerdings: die recovery tools sind -AFAIK- noch nicht so weit; zumindest kann man sie nicht im laufenden Betrieb einsetzen
ext4 hat wegen dem journaling nur den Vorteil, dass es bei unsauberen unmounts mit Hilfe des journals den konsistenten FilesystemZustand nur *schneller* wieder herstellen kann.
Der Lösung stehen also 400 € im Wege...
@joeAverage62 Gut zu hoeren. Mir hat das Konzept ja auch schon immer gefallen, ist halt etwas, was durch deutlich mehr Einsatz reifen musste. Und der Erfahrungswert war da ja erstmal ein anderer. Jetzt war das bei mir ja bloss das filessystem fuer das OS selbst. Wenns um solche 16TB Festplatten gibt ist dann ist eher die frage btrfs oder zfs, wenn man sich denn von ext4 weg traut.
So, neue Platte ist bestellt.
Wenn ich sie mit Linux Mint Live mit BTRFS formatiere und dann unter Windows befüllen möchte, würdet ihr hier sowas vertrauen?
Wenn ich sie mit Linux Mint Live mit BTRFS formatiere und dann unter Windows befüllen möchte, würdet ihr hier sowas vertrauen?
wenn du eh ein Linux brauchst, würde ich direkt beim Orginal bleiben; means: BTRFS ist ein in-kernel-Modul, welches mit einer Linux-distro kommt
- ich kenne zwar die Datenrate der USB-Platte und auch den Füllstand deiner alten Platte nicht - aber ich würde beide Platten temporär in einen PC mit gescheitem SATA-Controller schrauben und dann kopieren.
Vlt. auch mit einer schlankeren - schätze Mint-Live ist fett - Linux-Live-Distro auf'm USB Stick, z.B: sysrescue
Du hättest dann auch "rsync" zum Kopieren zur Verfügung ...
Tip:
falls du dich dennoch für die Windows-Variante entscheidest:
PowerSparTechniken vorm Kopieren auf OFF (AFAIK, langwieriges Copy ( geschätzt: mehr als 20 h) wird nicht unbedingt als Aktivität auf dem PC vom windows wahrgenommen.
means: Der PC fährt während des Copy in den Schlafmodus...
USB Platten aus Gehaeuse rausnehmen um Daten zu kopieren - und dann wieder zurueck - macht nicht soviel Sinn.
Selbst wenn man mal USB Platte kauft weil guenstiger als SATA um sie permanent zu entfernen sollte man auf jeden Fall vor dem Entfernen die Platte gut lese/schreib-testen. Also linux badblocks oder so durchlaufen lassen.
Zweitens ist USB 3 jetzt auch nicht mehr wirklich langsamer als SATA. Kriege ich auch immer ca. 190 MByte/sec hin.
Drittens kann man nicht ausschliessen, das selbst bei den neuesten USB Gehaeusen da immer noch ein Arschcontroller drin sitzt, der erst bei Block 1 (ich glaube das war block 1, irgendein kleiner offset) anfaengt die Platte zu nutzen. Mit dem Erfolg, das wenn man die Platte auf SATA beschreibt, man die Platte nicht unter USB nutzen kann. Und imgekehrt. zumindestens nicht ohne grosse hacks.
btrfs unter windows wuerde ich nicht vertrauen fuer so eine Aktion. Scheint frische Bastelarbeit. Man kann ja auch unter linux gut kopieren. Oder halt mal ein wenig Geld abdruecken und ext4 fuer windows von Paragon kaufen. Wer soviel Geld fuer Platte hat, hat auch das Geld fuer die passende Weichware.
Oder halt mal ein wenig Geld abdruecken und ext4 fuer windows von Paragon kaufen.
Ja, aber die Bezahlsoftware kann BTRFS nur lesen nicht schreiben...
Sehe ich so ähnlich wie te36. Außer - ich denke Paragon Treiber braucht man nicht mehr zu kaufen. Selbst zwar nicht probiert, aber WSL sollte auch gehen. Get started mounting a Linux disk in WSL 2 | Microsoft Learn
Selbst nehme ich Samba Freigabe auf Linux System und bespiele das von Windows aus, wenn nötig. Klar, kann mal 1,5 Tage statt 1 Tag dauern bei großer Platte. Aber total mühelos - ich lasse die Rechner halt werkeln, braucht nicht mein Beisein. Wie bereits erwähnt, ggf. Schlafen temporär deaktivieren.
btrfs kann schon interressant fuer so grosse datenplatte sein wegen der daten checksums. Allerdings kann man sich das unter linux auch leicht mit boardmitteln machen. Und wenn Du Kopien auf verschiedenen Platten/FS hast willste checksums eh nicht (nur) im Filesystem, sondern auch so als Datei das du die von den verschiedenen Platten vergleichen kannst. Von daher waere halt ext4 die sicherere/feigerere Wahl mit der Du halt auch die Moeglichkeit haettest unter Windows zu schreiben.
wenn Du Kopien auf verschiedenen Platten/FS hast willste checksums eh nicht (nur) im Filesystem, sondern auch so als Datei das du die von den verschiedenen Platten vergleichen kannst. Von daher waere halt ext4 die sicherere/feigerere Wahl
sorry , aber deine Schlussfolgerung erschliesst sich mir nicht !
weil, was hielte mich denn davon ab zusätzlich jede Datei mit einer -z.B.- MD5 zu versehen - ganz unabhängig vom Dateisystem -
bei wichtigen Dateien (aufgehobene Bios (!), fette Medidateien, etc.) machen *ich* immer:
mds5um datei-name > datei-name.MD5
recheck:
md5sum -c datei-name.MD5
und über directories:
find . -type f -print0 | xargs -0 md5sum >> MD5_$(date +%F);
recheck dann mit:
md5sum -c MD5_* | grep -vi OK
Ich glaube das nennt man "violent agreement". Man streitet sich, weil man nicht merkt das man dasselbe meint 
Genau solche Checksum files, die man erstellt meinte ich. Und die kann man dann vergleichen fuer die verschiedenen Kopien der Dateien auf verschiedenen Platten mit moeglicherweise verschiedenen filesystemen.
Aber wenn man das macht, dann faellt halt ein vorteil von btrfs/zfs weg, naemlich das fuer dich zu machen. Da kann man dann also als kleiner Feigling ("ich will nix neues unerprobtes") eben auch gut bei ext4/ntfs bleiben.
dann faellt halt ein vorteil von btrfs/zfs weg, naemlich das fuer dich zu machen
Der grösste Vorteil von btrfs in diesem thread war - m.M.n. - das es keinen filesystem-check bedarf, wenn die Platte aus irgendeiner Grund unsauber abgehangen wurde ...
Das mein Punkt !
Halte ich nicht fuer einen relevanten Benefit. Wenn es keine unerwartete Probleme gibt, dann kann man nach crash / unerwartetem Stromverlust ext4 genau so gut wieder zum laufen bringen, wie btrfs. Journal restore ist sehr schnell. Maximal ein paar sekunden bei rotierender platte. Schneller bei SSD.
Wichtig ist eigentlich nur, wie gross die chance auf unerwartete Probleme ist. Und da hat ext4 mit seinem journal mechanisms halt sagen wir mal ein Jahrzehnt mehr Erfahrung mit, solche Macken auszuraeumen, als btrfs.
sagen wir mal ein Jahrzehnt mehr Erfahrung mit
soso ?!
lt . wiki
Erstveröffentlichung:
ext4: 14.10.2008
btrfs: 12.06.2007
zu ext4
Nachteile:
Zitat: "Zeitverzögerte Allokation von Dateiblöcken und Inodes erhöht das Risiko von Datenverlust bei Abstürzen oder Stromausfall. In Kernel Version 2.6.30 wurde dieses Problem gegenüber früheren Versionen entschärft."
Hehe. gute Recherche. Ich hab das mal so gefuehlt geschaetzt ohne nachzuschauen, einfach nur wieviel oder wie wenig man so von aussen von btrfs gehoert hat. Probiers halt aus und mach Deine Erfahrung. Solange Du backup hast geht ja fast alles. Bei sowas wie file systems dauerst ja teilweise ewig bis man da mal mit allen interessanten Unfaellen konfrontiert ist, um die sinnvoll vergleichen zu koennen.
noch ist meine neue Platte nicht da. Und ich habe noch Zeit mich zu entscheiden, welches FS ich nun nehme 
achso, ich konnte eine Testplatte mit WSL unter Win11 mounten. Das war aber sehr hakelig und stürzte auch ab, so dass ich das WSL rebooten musste. Also das nehme ich schonmal nicht. Wohingegen der WinBtrfs Treiber keine Probleme bisher machte und auch viel einfacher zu installieren war. Ob ich mir nun den Ext4 Kauftreiber zulege, überlege ich mir noch..
So, ich möchte mal berichten...
Meine Platte kam am Mittwoch. Ich habe mich für Btrfs entschieden.
Also mit Linux Mint und Geparted formatiert auf Btrfs. Ich wollte aber unbedingt unter Windows befüllen. (diverse Gründe)
Also den WinBtrfs Treiber von github installiert, Platte im USB3 Rahmen wurde unter Windows erkannt.
Und es geht los mit dem Kopieren.
Nach 4 TB werde ich nachts geweckt, "Schreibfehler - Platte ist Voll" (obwohl noch 12 TB frei)
Andere Kopiervorgänge mit anderen Dateien keine Probleme.
Dennoch immer wieder Schreibfehler.
OK, Platte in anderen USB Rahmen gebaut
Neu unter Linux Mint formatiert.
Starte Kopiervorgang unter Win neu.
Nachts bei 4 TB und haargenau der selben Datei, wieder Schreibfehler
OK, Platte gelöscht, NTFS formatiert und Kopiervorgang gestartet.
Nach 18 Stunden - Alles ohne Murren kopiert!
OK, also liegts wohl am WinBtrfs Treiber.
Platte neuformatiert mit Btrfs und gleich an meinen Intel Nuc mit LE 11.01 gestöpselt.
Jetzt Befüllen über Netzwerk.
Nach ein paar Stunden Abbruch, weiß bis jetzt nicht warum. Platte war auf einmal am Nuc nicht mehr gemountet.
Kopiervorgang an der Stelle fortgesetzt.
Jetzt lief es durch bis zum Ende.
Alle Filme und Dateien (11 TB) erfolgreich kopiert.
Das Sync Tool sagt alles sei identisch.
Jetzt mach ich die Tage mal einen Dateiinhalt Test ob auch jedes Byte gleich ist, nur um auf Nr. Sicher zu gehen. (das mache ich alle paar Monate mal)
Fazit: Also erstmal ein Zwischenerfolg. Jetzt muss sich die Platte beweisen, ob ich da auch Schreibfehler kriege beim wöchentlichen Backup, so wie es beim NTFS war.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
