Lesson learned: dd oflag=direct
Mein Notebook ist heute beim Kopieren des UCS-4.3-4 ISO-Images auf einen USB-Stick abgestürzt. Was war passiert?
Mein L470 Notebook stürzt regelmäßig nach der Bahnfahrt beim Docken hier in Bremen ab.
Deshalb hatte ich vor einiger Zeit mal /proc/sys/kernel/hung_task_panic
und Konsorten auf 1 gesetzt, um irgendwie dem Grund für die Abstürze zu finden.
Es hat leider nicht geholfen und mir schlussendlich den heutigen Absturz beschwert:
Der Linux-Kernel überprüft alle 2 Minuten (hung_task_timeout_secs
), ob es Prozesse gibt, die unverändert im nicht-unterbrechbaren Schlafzustand verharren.
Die Einstellung sorgt nun dafür, dass der Kernel das nicht nur meldet, sondern mit einem OOPS auch stehen bleibt.
Ausgelöst wurde das nun heute durch den dd
-Aufruf:
das 1 GB große Image passt locker in die 16 GiB Arbeitsspeicher und landet deshalb bereits nach 2 Sekunden innerhalb des Linux-Kernel im Write-Back-Cache.
Damit hat dd
seine Arbeit erledigt und wartet dann nur noch mit einem f(data)sync()
-Aufruf darauf, dass der Linux-Kernel die Daten auch irgendwann alle geschrieben hat.
Bei 2.9 MB/s dauert das aber gut 7 Minuten, weshalb khungtaskd
den dd
-Prozess als „in sync()
hängend“ erkennt und den OOPS auslöst.
Oops 😳
Es empfiehlt sich deshalb dd oflag=direct [status=progress]
zu verwenden, denn das umgeht den Linux-Kernel Write-Back Cache, so dass dieser nicht mit den Einmaldaten des ISO-Images versaut wird und man auch die tatsächliche Schreibrate mitbekommt – die ist eben nicht „459 MB/s“ 😉