@Zhenwu
Deine Dateisystem(e) sind als dirty markiert, d.h. nicht ordentlich ausgehängt/heruntergefahren.
Das openSUSE die Platten mounted und Arch Linux nicht liegt sicher daran dass Arch schon den neuen ntfs3 Kernel-Treiber nutzt, während openSUSE den bewährten ntfs-3g Treiber nutzt. Arch Wiki hat einen
Eintrag dazu. ntfs-3g mounted auch dirty Dateisysteme, ntfs3 weigert sich.
Die eigentliche Frage ist warum die Dateisysteme überhaupt dirty sind. Wenn man ordentlich herunterfährt und den Schnellstart deaktiviert hat, dann kann es auch ein Windows-Bug sein, dann hat man halt Pech 🤷♂️ Langfristig sollte man NTFS ganz meiden.
Zhenwu schrieb:
An anderer Stelle liest man das ntfsfix nicht unbedingt das mittel der Wahl sein sollte.
ntfsfix ist weniger raffiniert als chkdsk und die Reparaturversuche gelten als krude weil sie stellenweise Datenverlust in Kauf nehmen. Alternativ unter Windows
chkdsk /F.
Nachdem das dirty flag entfernt wurde sollte man beobachten ob das Problem wieder auftritt nachdem man die Platte das nächste mal unter Windows gemounted hat und runterfährt. Wenn nicht dann ist gut, alles so belassen.
Verbliebt das dirty-Flag aber regelmäßig wieder kann sich behelfen indem man mit der mount-Option
force ntfs3 zwingt die Platte doch zu mounten oder auf den älteren ntfs-3g umstellt. Musst du in deiner Distribution/Desktop gucken wo du diese Optionen dauerhaft einstellen kannst.
Sebbi schrieb:
Da die externen Platten nicht gecached werden, ist die Daten ja geschrieben, das ist ja nicht das Thema. Das Problem sind aber die noch offenen Pipelines und Handles, auch wenn diese nur lesend sind. Es ist dadurch immer noch das dirty Bit vorhanden.
Das' doch quatsch, das dirty Bit steht ja auch auf der Platte geschrieben. Offene Handles kann es nur geben solange das Dateisystem noch eingehängt ist. Das Aushängen bricht ab wenn es noch Handles gibt. ("Das Gerät wird gerade verwendet.").
Erst wenn es keine Handles mehr gibt und alle Daten gesynced sind macht das Aushängen einen letzten Schreibbefehl auf die Platte der das dirty-Bit entfernt.
Sebbi schrieb:
Wenn die HW eben nicht rechtzeitig aufwacht, weil die im Sleepmodus war [...] dann denkt Windows, das Gerät regaiert nicht mehr und setzt dort das Messer an.
Halte ich für eine steile These. Im normalen Betrieb wartet Windows ja auch lang genug dass HDDs anlaufen können. App gibt Schreibbefehl an Windows, Windows gibt Schreibbefehl an USB-Gerät, USB-Gerät weckt erstmal die Platte und solange blockieren die Befehle, das äußert sich dann in eingefrorenen Anwendungen.
Bestimmt gibt es irgendwann einen Timeout, vielleicht ist der beim Herunterfahren sogar kürzer als im normalen Betrieb, aber meine Erfahrung ist, dass Windows genau dann abschaltet, wenn die Festplatt fertig angelaufen ist. Das sieht dann vielleicht so aus als ob Windows zu schnell war; das Anlaufen dauert ein paar Sekunden, der eigentliche Schreibbefehl der das Dateisystem nicht-dirty markiert nur ein paar Millisekunden. Aber das Aushängen der Dateisysteme ist auch fast der letzte Schritt, danach kann Windows sofort abschalten.
Sebbi schrieb:
Ein normales Verhalten, denn genauso werden auch festhängende Programme behandelt, die ja ggf der Grund für das Herunterfahren sind. Da wird dann nicht mehr "lieb gefragt, ob der Prozess sich bitte beendet" , sondern es wird nach einer gewissen Zeit ohne Reaktion der Taskkill durchgeführt, um das "saubere" Herunterfahren des Systems zu gewährleisten.
Aber Prozess-Management und I/O-Devices sind zwei völlig verschiedene Subsysteme, es gibt keinen Grund anzunehmen dass die gleichartig behandelt werden?! Die Prozesse müssen strikt vorher beendet werden weil die ja noch Daten schreiben können. Erst danach kann man die Dateisysteme aushängen.
Also dass Windows Schreiboperationen zu früh aufgibt halte ich für Unsinn solange die Platte keinen mechanischen Schaden hat und außergewöhnlich lange braucht. Meine Vermutungen wären
- Der USB-Adapter ist fehlerhaft und quittiert schon besagten letzten Schreibbefehl, obwohl der seitens der SATA-Platte noch gar nicht fertig war.
- Irgendein Hintergrundprozess/Dienst oder vllt. auch ein Treiber gibt seine letzten Handles nicht auf bzw. lässt sich nicht beenden und daher kann Windows das Dateisystem gar nicht sauber aushängen. Es wäre durchaus plausibel dass das auch NUR beim Herunterfahren passiert und nicht beim manuellen "Sicher entfernen"; Mittem im Herunterfahren wurden schon allerlei Prozesse/Dienste beendet und nur unter diesen Umständen gibt es bei der schuldigen Software ein Fehlverhalten.
