USB Festplatte - Dolphin / Plasma freeze

**Click** · 14.01.10, 16:50

Hallo zusammen,

ich bin mir noch nicht siche,r ob ich das richtige Forum getroffen habe, aber ich denke schon.

Wenn ich bei meinem openSUSE 11.2 (war aber bei 11.1 auch schon so) eine USB Festplatte reinstecke und sie mounte, "friert" mein Plasma Desktop "ein", bzw. wenn ich mit Dolphin auf sie zugrefifen will "friert" auch Dolphin ein. Erst nach einigen Minuten sind Plasma und Dolphin wieder funktionsfähig und ich kann mit Dolphin auf die Festplatte zugreifen.
Dies passiert wenn Dolphin es mountet, wenn es übner den DeviceManager gemountet wird, aber auch, wenn ich es manuell per konsole mounte.

Der Freze ist sofort beendet, wenn ich den USB Stecker einfach wieder aus der Festplatte ziehe.

Das kuriose an der Sache ist jetzt, dass ich in der Zeit, in der Dolphin und Plasma "eingefroren" sind sehr wohl per konsole als auch per konqueror im Dateimanager Modus auf die Platte zugreifen kann.

Und noch komischer:
ich habe auf einer anderen Platte ebenfalls ein unabhängiges openSuse 11.2, mit gleicher KDE Version, bei der diese Probleme nicht auftreten.

Die Frage ist: Was ist hier los? Das "einfrieren" ist nämlich schon ziemlich ätzend und beeinflusst auch ganz schön das Arbeiten.
Und was haben Dolphin und Plasma, was der Konqueror im Dateimanager Modus nicht hat?

Viele, viele Fragen, kann mir wer die Antwort sagen? :-P

Viele Grüße,
Click

Achja: benutzte zur Zeit KDE 4.4 RC1, tritt aber schon lange auch mit alten Versionen auf.

**Aqualung** · 14.01.10, 16:55

wechsle mit "strg-alt f2" auf eine Textkonsole, log Dich als root ein und poste

Code:

dmesg

Mit "strg-alt f7" kommst Du zurück auf Dein X.

**Click** · 14.01.10, 18:58

Das passiert, wenn ich die Platte anstecke:

Code:

[ 8408.546038] usb 1-8: new high speed USB device using ehci_hcd and address 8
[ 8408.810037] usb 1-8: New USB device found, idVendor=1058, idProduct=1102
[ 8408.810052] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8408.810057] usb 1-8: Product: My Book
[ 8408.810061] usb 1-8: Manufacturer: Western Digital
[ 8408.810066] usb 1-8: SerialNumber: 57442D574341553433323137303635
[ 8408.810172] usb 1-8: configuration #1 chosen from 1 choice
[ 8408.856387] scsi8 : SCSI emulation for USB Mass Storage devices
[ 8408.856748] usb-storage: device found at 8
[ 8408.856752] usb-storage: waiting for device to settle before scanning
[ 8408.923389] input: Western Digital My Book as /devices/pci0000:00/0000:00:13.5/usb1/1-8/1-8:1.1/input/input7
[ 8408.923496] generic-usb 0003:1058:1102.0003: input,hidraw1: USB HID v1.11 Device [Western Digital My Book] on usb-0000:00:13.5-8/input1
[ 8409.883441] scsi 8:0:0:0: Direct-Access     WD       My Book          1028 PQ: 0 ANSI: 4
[ 8409.883619] sd 8:0:0:0: Attached scsi generic sg3 type 0
[ 8409.883881] usb-storage: device scan complete
[ 8409.906076] sd 8:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[ 8409.919325] sd 8:0:0:0: [sdc] Write Protect is off
[ 8409.919343] sd 8:0:0:0: [sdc] Mode Sense: 10 00 00 00
[ 8409.919346] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[ 8409.955066] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[ 8409.955085]  sdc: sdc1
[ 8410.001957] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[ 8410.001973] sd 8:0:0:0: [sdc] Attached SCSI disk

Dann frieren Plasma und Dolphin ein. Auf nachdem das vorbei ist kommen aber keine neuen Meldungen mehr.

**Aqualung** · 16.01.10, 07:54

Die Meldungen sehen gut aus.

So wirst Du wohl mit dem Bug leben müssen.

Merke: Eye-Candy sorgt öfters für komische Probleme.

http://de.wikipedia.org/wiki/Eye_Candy

**Click** · 16.01.10, 08:33

Aber es kann ja kein "normaler" Bug, der bei jedem auftritt, sein, da es ja zB auf meinem zweiten System nicht so passiert.
Und dann wäre noch die Frage, weshalb Dolphin zB einfriert und der konqueror nicht?

**chromium** · 27.01.10, 17:08

Click,

Ich kann dir sehr wahrscheinlich helfen, falls das Filesystem auf dem USB Disk ein VFAT System ist. Ich gehe auch davon aus, dass der Freeze nur passiert, wenn die Platte auch gemountet wird. Könntest du diese beiden Annahmen bestätigen? Falls sie nämlich nicht zutreffen, trifft auch meine Vermutung bezüglich deines Problems nicht zu und es macht keinen Sinn dass ich weiterfahre.

Bis dann

**Click** · 29.01.10, 12:37

Bestätigt

Ich bin gespannt auf deine Lösung *freu* :P

**chromium** · 29.01.10, 15:33

Ok, dann solltest du jetzt als nächstes die Disk von Hand mounten, um zu verifizieren dass das Problem von dort her kommt wo ich es vermute. Deinem früher publizierten Output von dmesg entnehme ich, dass die Disk mit einer Partitionstabelle versehen ist (was eigentlich nicht notwendig ist, falls schlussendlich doch nur eine Partition vorliegt). Deshalb wird der Device welcher zum Zug kommt sowas wie /dev/sdb1 oder /dev/sdc1 heissen. Häng also die Platte wieder an und finde heraus welche Device diesmal verwendet wird. Ich geh mal davon aus, dass es wiederum /dev/sdc1 ist. In einer Root Shell kannst du dann zwischen zwei Arten des Mounting hin- und her-togglen:

mount -t vfat -o usefree /dev/sdc1 /mnt

umount /mnt

mount -t vfat /dev/sdc1 /mnt

umount /mnt

.
.

Ich rechne jetzt eigentlich damit, dass immer dann wenn die Option "usefree" verwendet wird, der Desktop Freeze nicht auftritt. Die console wird ja vom Freeze nicht betroffen, du könntest im jeweiligen Freeze den Umount also absetzen. Der Device wird aber solange busy sein bis der Freeze vorbei ist.

Falls du dieses Verhalten beobachtest, können wir uns dann darüber unterhalten was zu tun ist.

Bis dann.

**Click** · 29.01.10, 17:16

Hey,

wahnsinn, es ist alles wie du es prophezeit hast :P

also mit der Option -o usefree habe ich keine freezes, nur ohne die Option.

Auf was lässt das jetzt schließen? Hat die Option irgendwelche Nachteile? Wenn nein, warum nimmt man sie nicht generell, oder warum tritt der Freeze nur bei mir auf?

Und last but not least:
Wie sag ich KDE, dass er die Option verwenden muss?

Viele, viele Fragen auf dessen Antwort ich gespannt bin. Vielen Dank erstmal bis hierhin, du hast mir schon extrem viel weiter geholfen!

**chromium** · 29.01.10, 19:50

Es ist klar was abläuft. Die Verwendung der Option ist übrigends nur dann schlecht, wenn du den Disk auch manchmal an einen Windows Rechner hängst. Trotzdem gibt es als schnellen Workaround wohl keine Alternative. Dazu weiter unten mehr.

Zum Sachverhalt selbst: Es kann vorkommen, dass Windows die Free-Block-List (FBL) des FAT Filesystems korrumpiert. Ich nehme an, dass dabei benutzte Blöcke auf diese List getan werden und deshalb überschrieben werden, was natürlich ein Katastrophe ist. Linux wehrt sich dagegen, indem nach dem Mounten des Disks eine aktuelle FBL erstellt wird. Dazu muss natürlich der ganze Disk (respektive die ganze Partition) gescannt werden und wenn es sich um grosse Datenmengen handelt, geht das einige Zeit. Mit der Option usefree sagst du dann eben, dass genau das nicht getan werden soll. Stattdessen soll der FBL des Disks vertraut werden.

Falls es nun so wäre, das während des Scans alles einfrieren würde, würde man schliessen, dass der Scan halt synchron (im Kernelspace) abläuft und dass sich deshalb während des Vorgangs im Userspace nichts tun kann. Dann könnte man sich natürlich nur noch mit der usefree Option helfen.

Es ist aber so, dass die Konsole, du sagst auch Konqueror und meines Erachtens andere Komponenten ganz normal verhalten. Firefox hat auch keine Probleme. Sogar der Window Manager funktioniert, jedenfalls im "focus follows mouse" Modus. Das Panel funktioniert aber nicht und deshalb kann man nicht zu einem andern Desktop wechseln, was das Ganze vor allem unerträglich macht.

Damit ist bewiesen, dass die Haltung. man müsse den Freeze in Kauf nehmen wenn man den Scan will, Unsinn ist. Es ist ganz einfach so, dass gewisse KDE4 Komponenten sich einfältiger Verhalten, als dass sie das tun müssten. Deshalb werde ich einen Bugreport schreiben. Ich werde versuchen, genauer herauszufinden, wer der Uebeltäter ist. Er wird dann wohl etwa so tönen: "kio_blahblah freezes during VFAT freelist scan". Den Report werde ich an OpenSuse schicken. Falls dann sichergestellt ist, dass der Ball beim KDE liegt, würde der schon weitergereicht.

Ich möchte auf den Scan nicht verzichten, denn VFAT verwende ich nur, falls der Disk auch mal an einen Windowsrecher gehängt wird. Auch nach einem etwelchen Fix wird es so sein, dass nach dem Mounten der Disk erst zu Schreibzwecken zur Verfügung steht, wenn der Scan abgeschlossen ist. Aber das stellt ja kein Problem dar.

Da die Ausgangslage sehr klar ist, Ich rechne ich eigentlich damit, dass der BUG schnell gefixt wird. Trotzdem möchte auch ich schon vorher das Problem in den Griff kriegen.

Ein Ansatz wäre, nur ein relativ kleines Speichergerät zum Datenaustausch mit Windows zu benutzen und für grosse Disks, welche nur an LINUX Rechner kommen nur ext4 zu verwenden. Ich habe mir kürzlich zwei 1.5 TB ESATA + USB Platten bei einem Discounter gekauft. Als erstes habe ich jeweils ein ext4 System draufgetan. Original war wohl NTFS drauf, aber das interressiert mich gar nicht. Wenn dann der noch übrig gebliebene VFAT Device klein ist geht der Scan schnell. Das ist der Grund dafür, dass viel Leute gar nicht merken, dass auch sie vom Problem betroffen sind. MIt einem 20 GB USB Stick merkst du wohl kaum was. Es gibt viele Gründe, VFAT nicht zu verwenden, so zum Beispiel die Limitierung der Filegrösse auf 4 GB. Sag es, falls du Disks mit ext4 versehen willst und Hilfe brauchst.

Es lohnt sich sicher auch, der Frage nachzugehen ob es leicht sofort festtellbar ist, ob ein Windowsrechner zu den bösartigen gehört. Wenn wir also schon den Free-List-Scan ausschalten, wäre es wohl gut zu wissen wo man den entsprechenden Stick nicht reinstecken sollte. Ziel sollte es sein, das Mounting dergestalt zu konfigurieren, dass der Scan gezielt nur für eine Untermenge der VFAT Disks ausgeschaltet werden kann. Dann könntest du für grössere VFAT Disks oder Partitionen, welche du nie an einen Windows Rechner hängst den Scan auschalten und für den kleinen Device welchen du "durch den Schmutz ziehst" ;-) eben nicht. Dies sieht natürlich nach entsprechender HAL policy aus

.
.
key="volume.policy.mount_option.usefree" ...
.
.

Wir kommen wohl nicht drum herum. Ich kann dir jetzt noch nicht genau sagen, wie du es tun musst. U.U. gibt es Experten, welche mitlesen. Was uns nichts nützt, sind Vorschläge, welche dahingehen, dass das Automount System ausgetauscht wird. Ich verwende wie du Opensuse11.2 mit KDE4 und möchte auf "natürliche" Art dem Automounter beibringen für gewisse Devices eine entsprechende Option zu setzen.

Gib mir ein wenig Zeit. Ich melde mich.

**Schreibtroll** · 29.01.10, 20:27

Lange Rede kurzer Sinn...

Der TE scheint Wechseldatenträger manchmal einfach abzuziehen und nicht abzumelden. Daher die längeren Mount-Zeiten!

Deine Fehleranalyse ist ja super. Wir sind hier aber keine Wissenschaftler

Und nebenbei noch: FAT/NTFS ist geil wenn man die als Datenträger für Pingi nutzt. Müssen aber immer mal wieder unter Win defragmentiert werden. Viel Spass... Ich hab ihn auch,,, Unter Pingi allein wäre ext2 sinniger! Auf jedem Fall kein journailing-Datasystem