linux   filesystem

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“ 😉

Written on May 2, 2019