© Eugene Sergeev, 123RF
I/O-Operationen muss der Admin nicht zwangsläufig als Blackbox behandeln. Es gibt Tools, die haarklein beobachten, was sich dabei auf der untersten Ebene abspielt.
Der Admin sitzt grübelnd vor dem Rechner. Er tippt nichts ein, bewegt die Maus nicht – doch plötzlich hört er, wie die Festplatte anläuft. Vielleicht hat er auch eine SSD – dann hört er nichts, sieht aber die Kontroll-LED flimmern. Was hat die Platte aufgeweckt? Ein Hintergrundprozess? Eine Mail? Oder Malware?
Er kann das bis aufs letzte Bit nachvollziehen. Das Tool der Wahl dafür heißt »blktrace«. Es stammt vom Maintainer des Block-I/O-Layers im Linux-Kernel, Jens Axboe. Zudem ist das virtuelle Filesystem Debug-FS mit im Spiel, das zuvor gemountet sein muss. Bei etlichen Distributionen, etwa Ubuntu, ist das ohnehin der Fall – im Zweifel schafft
mount | grep debugfs
Klarheit. Sollte das Debug-FS nicht gemountent sein, holt er das per
mount -t debugfs debugfs /sys/kernel/debug
nach. Außerdem müssen »blktrace« und »blkparse« installiert sein. Andernfalls hilft zum Beispiel unter Ubuntu:
apt install blktrace
Nun lassen sich mit »blktrace« die Daten aller I/O-Operationen aufzeichnen und in ein File schreiben, beispielsweise mit:
blktrace /dev/sda
Das erzeugt im aktuellen Verzeichnis ein File »Device.blktrace.CPU-Nr.«, also etwa »sda.blktrace.0«. Dieses File analysiert:
blkparse -i sda.blktrace.0
Alternativ kann man beide Kommandos auch mit einer Pipe koppeln und auf Stdout schreiben beziehungsweise von Stdin lesen lassen:
blktrace -d /dev/sda -o - | blkparse -i -
Das Kommando ist als Root zu starten und wird per [Ctrl]+[C] abgebrochen, wenn die gewünschten Infos im Kasten sind. Andererseits lässt sich auch eine maximale Laufzeit vorgeben. Die Ausgabe sieht beispielsweise so aus wie in Tabelle 1 (der Tabellenkopf wird nicht mit ausgegeben).
|
Major, Minor |
CPU |
Seq. |
Timestamp |
PID |
Action |
RWBS |
Offset |
Size |
Command |
|---|---|---|---|---|---|---|---|---|---|
|
8,0 |
2 |
215 |
11.317949575 |
6113 |
A |
WM |
520097056 |
+8 |
<- (8,1) 520095008 |
|
8,0 |
2 |
216 |
11.317949735 |
6113 |
Q |
WM |
520097056 |
+8 |
[kworker/u16:2] |
|
8,0 |
2 |
217 |
11.317951097 |
6113 |
G |
WM |
520097056 |
+8 |
[kworker/u16:2] |
|
8,0 |
2 |
218 |
11.317952225 |
6113 |
A |
WM |
520097240 |
+8 |
<- (8,1) 520095008 |
|
8,0 |
2 |
219 |
11.317952426 |
6113 |
Q |
WM |
520097240 |
+8 |
[kworker/u16:2] |
|
8,0 |
2 |
220 |
11.317953678 |
6113 |
G |
WM |
520097240 |
+8 |
[kworker/u16:2] |
In diesem Beispiel sind Kernelthreads (»kworker«) am Werk, wie sie der Kernel gerne für asynchrone Aufgaben einsetzt. Sie laufen auf der CPU 2 und schreiben (Buchstabe »W« im Feld »RWBS«) ein paar Byte auf die erste Festplatte »/dev/sda« (Major-/Minor-Number »8,0«). Die Codes im Action-Feld bedeuten hier:
»A« – IO was remapped to a different device, »Q« – IO handled by request queue code, »G« – Get request.
