Neue SSD: Shell-Skripte schreiben Dateien nicht mehr sofort

L

LinuxPC

Gast
Ich hatte vorher eine Crucial MX100, die ich jetzt durch eine Samsung 980 M.2 SSD ersetzt habe. Ich habe festgestellt, dass ich in meinen Shell-Skripten nun nachdem eine Datei geschrieben wird, also z.b. "echo test > test.txt" ständig ein "sync" folgen lassen muss, weil ansonsten die erzeugte Datei noch nicht existiert bzw. von dem darauffolgenden Befehl nicht gefunden wird. Ich frage mich, wie das sein kann, und ob es ein Hardware-Problem ist. Es macht für mich momentan nicht so wirklich Sinn, denn die alte SSD war Jahre älter und dadurch auch um Welten langsamer. Das Problem jedoch deutet darauf hin, dass die neue SSD irgendwie langsamer ist und eine Verzögerung beim Schreiben erzeugt. Kann das jemand verstehen?
 
Nö, das wird aber auch nicht tatsächlich so sein. Zeig mal das Skript, das nicht (mehr) funktioniert, exakt.
 
  • Gefällt mir
Reaktionen: Piktogramm und tollertyp
das klingt oberfaul. denn normal ist das alles im cache und hat dann mit der storage, erst mal, nicht zu tun!

memtest, dmesg, bash -x, oder das volle programm mit strace -ff
 
GrumpyCat schrieb:
Nö, das wird aber auch nicht tatsächlich so sein. Zeig mal das Skript, das nicht (mehr) funktioniert, exakt.
Das hier reichte schon, ohne Skript: "echo test > test.txt; cat test.txt"
Wenn man das öfter hintereinander macht, dann existiert die Datei manchmal, aber manchmal auch nicht.

Allerdings weiß ich jetzt woran es lag: Ich war gar nicht auf der SSD unterwegs, sondern die ganze Zeit auf einem anderen Rechner im Netzwerk per SFTP. Und mir war das nicht bewusst. Dass man so keinen Cache hat, ist ja klar. Tut mir leid, bin gerade bisschen überarbeitet.
 
bei einem ordentlichen netzwerk datei system, sollte das auch funktionieren. voraus gesetzt kein anderer arbeitet parallel damit

sobald du was auf fuse basis hast (und das sind alle, sshfs und sonstige komische sachen) ist jedoch alles möglich da gibts keine garantie
 
  • Gefällt mir
Reaktionen: Piktogramm
Das war sowas hier: "/run/user/1000/gvfs/sftp:host=xxx.xxx...". Wie genau das funktioniert, weiß ich nicht. Man hat seine Shell und eigene Umgebung lokal und das Dateisytems des fremden Hosts ist erreichbar. Wenn man direkt draufgehen würde per SSH und somit die Host-Umgebung nutzen würde dann gäbe es dieses Problem wohl nicht.
 
Oh also fuse würde das auch schon richtig machen, schätze ich mal.
gvfs aber... naja, das ist wohl eher bestenfalls für sowas wie "Browsing von Ordnern auf Netzwerk-Shares" gedacht.
 
  • Gefällt mir
Reaktionen: LinuxPC
Zurück
Oben