Prozess jbd2 blockt USB-Stick

[debianoli]

Hallo,

ich habe an einem Rechner mit Jessie - Kernel 3.16.0-4-amd64 - und KDE4 ein Problem mit einem USB Stick mit ext4:

Wenn ich den Stick über KDE gemountet habe, lässt sich der Stick nicht mehr unmounten. lsof ermittelt den Prozess jbd2 als Schuldigen. jbd2 kümmert sich um das Journaling von ext4. Das Blöde dabei: Ich kann jbd2 nicht killen. Den Stick kann ich nur nach einem Shutdown entfernen

Durch ein manuelle e2fsck -f /dev/sdc1 konnte ich das Problem beheben, aber ich möchte sichergehen, dass es nicht mehr auftritt. Sonst müsste ich jeden Stick vor dem Mounten immer per e2fsck prüfen und das vergesse ich zu leicht.

Eine Netz-Recherche wirft einige Treffer zu jbd2 und "blocks device" aus, aber richtig schlau bin ich aus den Ergebnissen nicht geworden. Ist das jetzt ein immer noch vorhandener Kernel-Bug oder startet ein KDE-Prozess jbd2 für den USB-Stick? Und wie kann ich jbd2 killen?

[rendegast]

Jegliches USB-device mit einem ext4-FS?
Probleme mit kde automounter?

Ein Hardware-Fehler bedingt einen FS-Fehler bedingt jbd-Fehler?
Interessantes in 'dmesg'?

Mal Stick-Image sichern, dann

Code: Alles auswählen

badblocks -svw /dev/sdX

Das ohne kde und dessen automounter.

[debianoli]

OK, ich habe den Auslöser gefunden:

Auf dem Stick ist eine verschlüsselte Image-Datei mit ebenfalls ext4 Dateisystem. Diese mounte ich dann immer händisch als Loop-Device. Das geht in Jessie ohne große Angabe von Optionen mit

Code: Alles auswählen

mount /media/user/stick/crypt.img /home/Mountpunkt

.
Ich habe den Fehler gemacht, dass ich das Aushängen auch nur mit umount gemacht habe. Doch dazu braucht man zwingend umount.crypt und dann bekommt man diese Meldung (die auch bei mount.crypt erscheint, aber NICHT bei mount, obwohl mount auch das encrypted Image mountet):

Code: Alles auswählen

umount.crypt MountPoint/
NOTE: mount.crypt does not support utab (systems with no mtab or read-only mtab) yet. This means that you will temporarily need to call umount.crypt(8) rather than umount(8) to get crypto volumes unmounted.

Warum läuft aber jbd2 Amok und lässt sich nicht einmal killen? Das verstehe ich nicht ganz.

dmesg bringt im Übrigen keine Fehlermeldungen zum Stick, alles ganz normal.

[rendegast]

... mit einem USB Stick mit ext4:
... lsof ermittelt den Prozess jbd2 als Schuldigen. ...

Die ganze Ausgabe

Code: Alles auswählen

lsof | grep jbd
 oder auch
ps ax | grep jbd

hätte gezeigt, daß es sich nicht um ein
jbd2/sdXY .....
handelt (wovon ich nach obigem ausging),
sondern ein
jbd2/loopXXX ....
was dann wohl auch zum crypt-Image geführt hätte.

[debianoli]

Nein, bei dieser Ausgabe erscheint eben kein loop. Sonst wäre ich schneller auf der richtigen Spur gewesen. Zmindest bei der Ausgabe von lsof steht da nix.

Ich teste das heute noch mal und stelle die genause Ausgabe von lsof hier rein.

[debianoli]

Servus,

hier ist die Ausgabe von lsof, wenn man das encrypted device nur per umount aushängt:

Code: Alles auswählen

lsof | grep sdb1
jbd2/sdb1 2916             root  cwd       DIR              254,1      4096          2 /
jbd2/sdb1 2916             root  rtd       DIR              254,1      4096          2 /
jbd2/sdb1 2916             root  txt   unknown                                         /proc/2916/exe

Doch auch ein grepen nach jbd2 bringt nix:

Code: Alles auswählen

lsof |grep jbd
jbd2/dm-1  227             root  cwd       DIR              254,1      4096          2 /
jbd2/dm-1  227             root  rtd       DIR              254,1      4096          2 /
jbd2/dm-1  227             root  txt   unknown                                         /proc/227/exe
jbd2/dm-3  456             root  cwd       DIR              254,1      4096          2 /
jbd2/dm-3  456             root  rtd       DIR              254,1      4096          2 /
jbd2/dm-3  456             root  txt   unknown                                         /proc/456/exe
jbd2/sdb1 2916             root  cwd       DIR              254,1      4096          2 /
jbd2/sdb1 2916             root  rtd       DIR              254,1      4096          2 /
jbd2/sdb1 2916             root  txt   unknown                                         /proc/2916/exe

Ich seh da nix von Loop. Das ist auch ausgehängt.

Edit: Das selbe Spiel bei ps ax:

Code: Alles auswählen

ps ax |grep jbd
  227 ?        S      0:00 [jbd2/dm-1-8]
  456 ?        S      0:00 [jbd2/dm-3-8]
 2916 ?        S      0:00 [jbd2/sdb1-8]
 3004 pts/1    S+     0:00 grep jbd

[rendegast]

Das ist aber nicht der jbd, der für das Dateisystem auf dem verschlüsselten Image zuständig ist,
Das Dateisystem auf dem Stick ist dann wohl immer noch gemountet
und bedarf eines gesonderten umount resp. "Aushängen".

[debianoli]

Nein. Dieser Fehler tritt nur auf, wenn man das encrypted device mit dem Befehl umount aushängt. Dann blockt jbd2 das Aushängen von sdb1, auf dem sich das encrypted File befindet.

Ich schildere dir zu Sicherheit die genaue Konstellation bei diesem reproduzierbaren Fehler:

USB-Stick mit ext4-Partition (sdb1)

Auf dieser ext4-Partition ist ein img-File, das per LUKS verschlüsselt ist: container.img

Der verschlüsselte container.img enthält selber ein ext4-Dateisystem.

Also:

/dev/sdb1 gemountet unter /media/stick und dann /media/stick/container.img gemountet nach /home/user/Mountpoint

Das funktioniert alles ganz normal per mount.

Doch wenn ich

Code: Alles auswählen

umount /home/user/Mountpoint

mache, dann wird der eingebundene container.img auch ganz normal ausgehängt und erscheint auch nicht mehr bei zB df

Aber: In diesem Fall ist nun ein Aushängen von sdb1 NICHT mehr möglich, den jbd2 blockt das Device sdb1 und lässt sich als Kernel-Prozess nicht killen.

Sobald ich aber die EInbindung von container.img per

Code: Alles auswählen

umount.crypt /home/user/Mountpoint

löse, dann kann ich auch sdb1 wieder ganz normal aushängen. Der Prozess jbd2 hat kein Interesse an dem Stick.

Kurz gesagt: umount löst zwar die Einbindung eines encrypted Imgae-Files im Dateisystem, lässt aber im gegensatz zu umount.crypt einige (mir unbekannte) Parameter unberührt. Diese Parameter rufen jbd2 auf den Plan.

Ich hoffe, so wird das Auftreten des Fehlers verständlicher.