Anzeige:
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 15 von 24

Thema: USB Festplatte - Dolphin / Plasma freeze

  1. #1
    Registrierter Benutzer Avatar von Click
    Registriert seit
    Dec 2008
    Beiträge
    40

    USB Festplatte - Dolphin / Plasma freeze

    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.

  2. #2
    Registrierter Benutzer
    Registriert seit
    Jan 2008
    Beiträge
    2.551
    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.

  3. #3
    Registrierter Benutzer Avatar von Click
    Registriert seit
    Dec 2008
    Beiträge
    40
    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.

  4. #4
    Registrierter Benutzer
    Registriert seit
    Jan 2008
    Beiträge
    2.551
    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

  5. #5
    Registrierter Benutzer Avatar von Click
    Registriert seit
    Dec 2008
    Beiträge
    40
    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?

  6. #6
    Registrierter Benutzer
    Registriert seit
    Jan 2010
    Beiträge
    8
    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

  7. #7
    Registrierter Benutzer Avatar von Click
    Registriert seit
    Dec 2008
    Beiträge
    40
    Bestätigt
    Ich bin gespannt auf deine Lösung *freu* :P

  8. #8
    Registrierter Benutzer
    Registriert seit
    Jan 2010
    Beiträge
    8
    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.

  9. #9
    Registrierter Benutzer Avatar von Click
    Registriert seit
    Dec 2008
    Beiträge
    40
    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!
    Geändert von Click (29.01.10 um 18:33 Uhr)

  10. #10
    Registrierter Benutzer
    Registriert seit
    Jan 2010
    Beiträge
    8
    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.

  11. #11
    Registrierter Benutzer Avatar von Schreibtroll
    Registriert seit
    Jan 2009
    Beiträge
    644
    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

  12. #12
    Registrierter Benutzer Avatar von Click
    Registriert seit
    Dec 2008
    Beiträge
    40
    Bevor ich zum eigentlich Sinn meines Beitrages komme vorweg folgendes:


    Zitat Zitat von Schreibtroll Beitrag anzeigen
    Lange Rede kurzer Sinn...
    [...]
    Deine Fehleranalyse ist ja super. Wir sind hier aber keine Wissenschaftler
    Danke für diesen sinnlosen Beitrag. Wenn du an langen Fehleranalysen nicht interessiert bist, bitte ich dich auch nicht so einen Schwachsinn zu schreiben. Ich finde es sehr bemerkenswert, dass sich chromium soviel Zeit genommen hat um sich mit dem Problem auseinander zusetzen. Außerdem brauch man kein Wissenschaftler sein um das zu verstehen, sondern nur an dem Problem interssiert, da es gut verständlich geschrieben ist. Also anstatt Leute dafür zu beschuldigen, dass sie sich hier gründlich um Probleme kümmern wenn sie können udn Leuten wie mir echt weiterhelfen und durch solche Beiträge die Motivation verlieren, solltest du sowas einfach für dich behalten.



    Jetzt aber zur Fehleranalyse:
    Erstmal vielen Dank cromium, da mir deine Beschreibung bzw Analyse doch sehr weitergeholfen hat.
    Dass ich VFAT eigentlich nicht brauche, wenn ich nur mit Linux darauf zugreife ist mir bewusst, allerdings haben meine Wechseldatenträger (1TB Backup Platte, 500GB Media Platte, 16GB USB Stick) alle VFAT, da ich sie meistens mit Windows verwende (Backups, Daten Austausch, bzw Transport) oder andere Geräte darauf zugreifen müssen (DVD Player, Media Player). Mit der Einschränkung mit den 4GB pro Datei hatte ich auch noch keine großartigen Probleme, da ich diese Einzelfälle meist auf irgendeine Art und Weise umgehen konnte. Deshlab stellte sich VFAT als Partition für mich als Ideal vor.

    Zum Problem zurück:
    Ich danke dir sehr, dass du bereits einen Bug Report erstellt hast, sonst hätte ich das getan, sobald sich mein Problem nicht als Einzelfall rausgestellt hätte.

    Ich kann mir allerdings vorstellen, dass dieser Bug wirklich bei openSuse liegen könnte, da der Bug wohl wesentlich eher aufgefallen wäre, wenn es ein genereller KDE4 Bug wäre, der bei jedem auftritt. Aber das werden uns die Entwickler von openSuse ja hoffentlich bald genau sagen, ob der Fehler bei ihnen liegt.

    Eine sofortige Lösung für dieses Problem zu finden scheint mir ebenfalls recht unrealistisch, was für mich zur Zeit auch kein größeres Problem ist. Ich wäre schon zu Frieden, wenn das Problem mit den Freezes im nächsten Vierteljahr gelöst wird, da ich mich (traurigerweise) schon daran gewöhnt habe. Bis dahin kann ich in Einzelfällen, wenn cih die Platte sofort brauche auch manuell mounten.

    Ich kann also erstmal so weiterleben mit der Gewissheit, dass es immerhin schonmal einen Bug Report darüber gibt.

    Ich danke dir also sehr für deine Bemühungen und hoffe, dass der Fehler bald behoben wird, damit mein KDE4 auch weiterhin benutzbar bleibt, auch wenn ich eine Platte mounte

  13. #13
    Registrierter Benutzer
    Registriert seit
    Jan 2010
    Beiträge
    8
    Click,

    Code:
    /dev/sdb1 on /media/DRIVE-N-GO type vfat (rw,nosuid,nodev,uid=5083,utf8,shortname=mixed,flush,usefree)
    Wie du siehst bin ich stolzer Besitzer einer gesetzten usefree Option. Dabei wurde die Platte nicht etwa von Hand gemounted, sondern auf die normale Art über den KDE4 Device Notifier. Ich nehme an, das interressiert dich. Du kannst nämlich dann auf die übliche komfortable Art mit den removable VFAT Platten umgehen. Ich werde am Ende dieses Beitrages erklären wie man das bewerkstelligen kann. Ich hoffe du wendest den Fix auch an und gibst mir Feedback. Ich möchte ihn nämlich im Bugreport als Workaround angeben.

    Zum merkwürdigen Beitrag von Schreibtroll werde ich mich am Ende äussern. Diejenigen, welche die Sachlage verstehen, wissen ja, dass nicht der Free-List-Scan selbst, welcher durch "-o usefree" unterbunden wird, das Problem ist. Der wirkt sich normalerweise einfach als erhöhte Plattenaktivität im üblichen SInn aus. Schlimm ist dass sich in KDE auf Opensuse 11.2 die Hauptkomponente, das Plasma Desktop, einfriert, währenddem Einiges noch normal läuft.

    Zur Frage, welches Risiko man eingeht, wenn man den Scan ausschaltet möchte ich mich vorerst nicht weiter äussern. Jeder muss selbst entscheiden ob er das tun will. Jetzt geht es um die Frage, wie man in der KDE4 Umgebung (bei Openuse 11.2) für removable Devices mount Optionen setzt. Das ist eine Frage allgemeiner Natur und wird wohl auch diejenigen interressieren, welche gerne "noatime" setzen möchten.

    Bevor ihr euch jetzt hinsetzt und all die Dinge aufzählt, welche in diesem Zusammenhang üblicherweise geäussert werden - bitte zuerst zu Ende lesen. Insbesondere solltet ihr keine Beiträge verfassen, wenn ihr meint man könne mit Hal Policy Mount Options setzen (ich meine wirklich setzen, nicht etwa die Liste der "allowed options" verlängern) oder etwa via fstab. Alles bezieht sich natürlich lediglich auf Opensuse 11.2. Ich werde das von jetzt an aber nicht mehr speziell erwähnen.

    Es stellt sich heraus, dass es eigentlich keine "offizielle" Art gibt Mount Options für removable Devices zu setzen. Ich präsentiere hier eine Art, welche ich vorerst verwenden werde und hoffe, dass sie Click auch testet. Mir gefällt sie, es wird aber Leute geben, welche sie als Hack der übelsten Art bezeichnen werden. Alles ist schnell gemacht. Eine Policy Rule ein mv und die Platzierung eines kleinen Shellscriptes.

    Wenn es trotzdem ein offizielle Art gibt, Mount Options für removable Devices zu setzen, ums so besser. Aber wie gesagt, weiterlesen, damit nicht Dinge diskutiert werden müssen, welche ganz klar nicht funktionieren.

    Also, die Sache präsentiert sich so:

    Da wäre zuerst mal die Frage, ob es mit udev Rules gemacht werden soll. Das geht sicher. Man automatisiert da alles in einem frühen Stadium. Die Platten würden mit den korrekten Optionen (automatisch - ohne User Interaktion) gemountet. Man müsste sie dann aber via Root Shell umounten, sie würden dann nicht mehr durch den Device Notifier des Desktops manipulierbar sein. Das man das tun kann betrachte ich aber als Vorgabe. Natürlich wird längerfristig alles Richtung udev Rules und Verknüpfung der Desktop Manager damit gehen. Aber vorerst hilft das nicht.

    Dann kommt als nächstes die Frage, ist es schon DeviceKit oder spielt HAL immer noch eine Rolle? Es gibt Leute die behaupten, sie hätten Devices gemountet gekriegt mit nicht laufendem hald. Ich vermute aber, dass es sich dabei um Factory Versionen von Opensuse handelt. Auf 11.2 geht nichts ohne hald. Für den eigentlichen mount ruft er dann das Executable

    /usr/lib/hal/hal-storage-mount

    auf. Auch hier wieder: längerfristig überlebt HAL offensichtlich nicht und DeviceKit wird gewinnen, aber vorerst muss man sich um HAL kümmern. Damit die Konfusion richtig einfahren kann: Auch auf Opensuse 11.2 gibt es schon DeviceKit Komponenten.

    Aber wie gesagt, hald führt das Zepter. Dabei ist jetzt entscheidend, welchen Paradigma Wechsel die HAL Entwickler im Uebergang zur 0.5er Version vollzogen haben. Sie haben es nämlich plötzlich als störend empfunden, dass man Default Mount Optionen via HAL Policy setzen kann. Stattdessen verlangen sie, dass die Default Optionen für das Mounten von removable Devices aus der Dekstop Umgebung kommen. Dieser Ansatz ist sicher korrekt. Die Idee wäre also zum Beispiel, dass hald via dbus die Optionen bei Desktop Komponenten, welche Zugang zur Desktop Konfiguration haben, abfragen kann.

    Nachdem also mit dem Uebergang zu HAL 0.5 die Möglichkeit Mount Optionen via Policy Files zu setzen verschwunden ist, haben die Gnome Leute eine Möglichkeit geschaffen, dass man wenigstens via shell (gconftool-2) oder direktes Editieren von Config Files unterhalb von /system/storage.. mount Optionen angeben kann. Nichts dergleichen steht in der KDE4 Umgebung zur Verfügung. Man kann "formal" übrigends nach wie vor Mount Optionen via Policy File setzen. Mit der Methode, welche unten beschrieben wird, kann man nachsehen, dass wenn man das richtig macht, hald die entsprechenden Werte auch in entsprechenden Umgebungsvariabeln abgespeichert hat. Sie kommen aber einfach nicht zum Zuge.

    Es gibt Leute, welche behaupten, man könne via /etc/fstab auch Optionen für removable Devices setzen. In der Umgebung von der wir hier reden ist dies unmöglich. /usr/lib/hal/hal-storage-mount checkt den fstab File. Sobald dort ein LABEL oder eine UUID oder der Device Name einer Platte auftaucht weigert das Programm sich den Mount zu machen. Removable Mounts und fstab vertragen sich nicht. Das ist auch korrektes Verhalten Man kann sich all das direkt ansehen indem man hald im Verbose Mode im Vordergrund laufen lässt:

    Code:
    linux-nida:/home/rfb # /etc/init.d/haldaemon stop
    Shutting down HAL daemon
    linux-nida:/home/rfb # /usr/sbin/hald --daemon=no --verbose=yes
    Man sieht dann auch den Output von /usr/lib/hal/hal-storage-mount.

    Dann geistert auch noch sowas wie Mediamanagerrc irgendwo im ~/.kde Verzeichis umher, wo man Mount Optionen setzen kann. Das gehört aber zu Kde3.5 und wird unter KDE4 nicht mehr unterstützt.

    Es sieht also schlecht aus für das setzen von Mount Option und es sieht alles danach aus, dass die Optionen für den jeweiligen Filesystemtyp hardcodiert sind. Wenn man nach den Optionsnamen in den entsprechenden Executables oder Libraries sucht, gibt es genügend "binary file matches", damit das zutreffen kann. Natürlich wäre im Prinzip denkbar, dass trotzdem hald bei einem Agenten am dbus die Default Optionen erfrägt und dass der Agent konfigurierbar ist. Aber einen Konfigurationsfile mit entsprechendem Inhalt findet man nirgends. hald selbst kann man wie gesagt via Policy File Default Mount Optionen für das entsprechende Filessystem beibringen, aber die werden eben nicht mehr verwendet. Das hald selbst noch irgendwo einen Konfigurationsfile liest, wo Entsprechendes drinsteht kann ich ziemlich ausschliessen. Dazu habe ich hald genügend mit strace maltraitiert. Dass man Default Mount Options einfach partout nicht setzen kann wird noch durch folgenden Sachverhalt bestätigt: Nach wie vor wird die Liste der "allowed options" respektiert. Dort gehört weder usefree noch noatime dazu. Es wäre ja recht merkwürdig, falls man irgendwo mount Optionen setzen kann und dann noch via HAL policy der Raum der zugelassenen Optionen vergrössern müsste. Man könnte sich jetzt noch die Sources anschauen, aber für mich ist die Sache klar, durch einfaches Her-Editieren oder Eintragen kommt man nicht zu Mount Otionen für Wechselmedien.

    Wenn man jetzt trotzdem noch Mount Optionen gesetzt haben will muss man sich etwas einfallen lassen. Eigentlich wird es jetzt erst richtig interressant. So im Stil "jetzt erst recht". Als letze Hoffnungsschimmer präsentieren sich nämlich fast schon lächerliche Erwartungen, welche an folgende Ueberlegungen anknüpfen:

    Wir wissen ja, dass hald /usr/lib/hal/hal-storage-mount aufruft. Wenn das früher schon der Fall war, als hald die Optionen aus einem entsprechenden Policy File erhielt, dann hat sich hal-storage-mount die Optionen sicher nicht selbst beschafft sondern von hald übernommen. Es könnte ja sein, dass das immer noch so ist. Deshalb klemmen wir uns einfach zwischen hald und hal-storage-mount und schauen mal nach. Mit "dazwischenklemmen" meine ich Folgendes:

    Wenn man das binary executable /usr/lib/hal/hal-storage-mount umbenennt in sagen wir

    /usr/lib/hal/hal-storage-mount.bin

    und als /usr/lib/hal/hal-storage-mount ein bash script mit folgendem Inhalt installiert:

    Code:
    #!/bin/bash
    
    exec /usr/lib/hal/hal-storage-mount.bin "$*"
    Dann funtioniert alles wie bisher. Der Unterschied besteht darin,. dass jetzt vor dem fork-exec von hal-storage-mount.bin noch der fork-exec einer bash erfolgt, welcher das kleine Script abarbeitet. Die ganze Prozessumgebung wird einfach mit einer Indirektion übertragen. Das "exec" kann man weglassen. Dann bleibt die Shell am Leben, währendem hal-storage-mount.bin lebt. Dies ist eine unwichtige Frage. Nachdem der mount erfolgt ist ist eh alles weg. Bis jetzt haben wir also am Verhalten des Systems nichts verändert. Nun geht es aber darum nachzusehen, wie Daten an hal-storage-mount.bin übertragen werden. Natürlich könnten da viele Dinge ins Spiel kommen, Pipes, Sockets, Doors. Wir hoffen aber, dass "konventionellere" Dinge zum Zuge kommen. Wir wollen uns also das Prozess Environment, etwelche Argumente und auch ansehen, was via stdin daherkommt. Wir müssen damit rechnen, dass hald via die stdout-stdin pipe mit seinem Child redet. Für letzteres müssen wir alle Zeilen von stdin einlesen, in einem Array abspeichern und dann wieder rausschreiben. Das script. welches das tut sieht so aus:

    Code:
    #!/bin/bash
    
    # This script logs the environment, the arguments and everything
    # that comes in on stdin to /tmp/hal.log. Everything from stdin
    # is then piped to hal-storage-mount.bin.
    
    env > /tmp/hal.log
    echo --------------- >> /tmp/hal.log
    echo "$*" >> /tmp/hal.log
    echo --------------- >> /tmp/hal.log
    
    declare -a the_lines
    
    i=0
    while read a_line
    do
     the_lines[$i]="$a_line"
     i=$i+1
    done
    
    for i in "${the_lines[@]}"
    do
     echo -e "$i" >> /tmp/hal.log
     echo -e "$i"
    done | exec /usr/lib/hal/hal-storage-mount.bin "$*"
    Wenn man das Script dazwischen klemmt, wird die Freude gross. Wenn man nämlich dann via Device Notifier eine Platte mounted und sich anschliessend /tmp/hal.log ansieht, sieht man dass offensichtlich hal-storage-mount.bin die Liste der zugelassenen Optionen aus der Prozessumgebung nimmt. Die aktuell zum Zuge kommenden Optionen nimmt er von stdin. Zuerst kommt eine Lehrzeile daher, dann kommt ein Zeile mit dem Filesystem Typ und dann kommt eine Zeile mit den aktuellen mount Optionen getrennt durch Tabs (!). hal-storage-mount.bin verhält sich da pingelig. Ohne Tabs gibt es "invalid mount options". Um die Tabs zu sehen muss man /tmp/hal.log mit od -c anschauen.

    Damit ist das Vorgehen klar. Wir wollen auf der Optionszeile

    Tab usefree

    anfügen, falls der Filesystem Qualifier "vfat" lautet.

    Ein erstes Script nimmt die Information, um welches Filessystem es sich handelt aus der Umgebungsvariablen HAL_PROP_VOLUME_FSTYPE. Es geht im weiteren davon aus, dass die Optionszeile mit "uid=" anfängt:

    Code:
    #!/bin/bash
    
    # This script pipes everything from stdin to hal-storage-mount.bin.
    # If the environment variable HAL_PROP_VOLUME_FSTYPE is set to "vfat"
    # and a line starts with "uid=", "\tusefree" is appended to the line.
    
    declare -a the_lines
    
    i=0
    while read a_line
    do
     the_lines[$i]="$a_line"
     i=$i+1
    done
    
    for i in "${the_lines[@]}"
    do
     if [ $HAL_PROP_VOLUME_FSTYPE = "vfat" -a ${i:0:4} = "uid=" ]
      then
       echo -e "$i\tusefree"
      else
       echo -e "$i"
     fi
    done | exec /usr/lib/hal/hal-storage-mount.bin "$*"
    Ein alternatives Script geht nicht auf die Umgebungsvariable sondern wartet darauf, dass eine Zeile mit "vfat" daherkommt. Falls der Fall eingetreten ist wartet es bis eine "uid=" Zeile kommt und schickt dort die Zusatz Option hintendrein. Letzteres tut es einmal:

    Code:
    #!/bin/bash
    
    # This script pipes everything from stdin to hal-storage-mount.bin.
    # If it encounters a line reading "vfat", it will once append
    # "\tusefree" to a line, if that line starts with "uid=".
    
    declare -a the_lines
    
    i=0
    while read a_line
    do
     the_lines[$i]="$a_line"
     i=$i+1
    done
    
    status=0
    for i in "${the_lines[@]}"
    do
     if [ $status = 1 ]
     then
      if [ ${i:0:4} = "uid=" ]
      then
       echo -e "$i\tusefree"
       status=2
      else
       echo -e "$i"
      fi
     else
      if [ $status = 0 -a "$i" = "vfat" ]
      then
       status=1
      fi
      echo -e "$i"
     fi
    done | exec /usr/lib/hal/hal-storage-mount.bin "$*"
    Eigentllich weiss ich nicht, welches der beiden Scripte mir besser gefällt.

    Man kommt nicht darum herum, die Liste der "allowed options" entsprechend zu erweitern. hal-storage-mount.bin ist auch in dieser Beziehung pingelig. Bitte dies nicht mit dem eigentlichen Setzen der Option verwechseln. Dies ist der entsprechende Policy File:

    Code:
    <?xml version="1.0" encoding="ISO-8859-1"?>
    <deviceinfo version="0.2">
     <device>
      <match key="block.is_volume" bool="true">
       <match key="volume.fstype" string="vfat">
        <append key="volume.mount.valid_options" type="strlist">usefree</append>
       </match>
      </match>
     </device>
    </deviceinfo>
    Man kann ihn als

    /etc/hal/fdi/policy/50-usefree.fdi

    installieren. Weder Name noch Zahl ist wichtig.

    Alles was bis jetzt gesagt wurde dient eigentlich nur zur Information. Leute, welche lediglich die Methode benutzen wollen um Mount Optionen zu setzen müssen erst von hier an aufpassen. Ich gehe davon aus, dass eines der beiden Scripte zu diesem Zeitpunkt als

    /tmp/hal-storage-mount

    vorliegt und der Policy File als

    /tmp/50-usefree.fdi

    Ich nehme an ihr müsst die Fileinhalte via Cut and Paste aus meinem Beitrag nehmen. Ich habe kein Erfahrung mit Foren und meine irgendwo gelesen zu haben, dass man keine Anhänge anfügen darf. Falls es eine bessere Art gibt, die Scripte und den fdi File zu übermitteln mach ich das natürlich sofort.

    Das einzige was beim ganzen Verfahren passieren könnte (abgesehen von den üblichen Gefahren bei der Arbeit als Root) ist das, dass euer original hal-storage-mount executable verloren geht, zum Beispiel indem

    mv hal-storage-mount hal-storage-mount.bin

    nochmals gemacht wird, und zwar nachdem hal-storage-mount schon das Script ist. Das wäre natürlich fatal - die HAL installation ist dann kaputt. Deshalb schlage ich vor, dass der Originalfile mit

    chattr +i hal-storage-mount.bin

    immun gemacht. Durch

    Code:
    cd /usr/lib/hal
    cp hal-storage-mount.bin hal-storage-mount
    /etc/init.d/haldaemon restart
    könnt ihr jederzeit das Originalverhalten wieder herstellen. Es kann als nichts passieren. Falls ihr hal-storage-mount.bin dann entfernen wollt oder falls ihr in obiger Recovery ein mv stat ein cp machen wollt müsst ihr natürlich ein

    chattr -i hal-storage-mount.bin

    durchführen.

    -----------------------------------------------------------------------------------
    Ok dann, ab hier für diejeneigen, welche einfach den entsprechenden Setup durchführen möchten und an meinen obigen Ausführungen nicht interresiert sind. Wie gesgt,

    /tmp/hal-storage-mount
    /tmp/50-usefree.fdi

    müssen entsprechend vorliegen und jetzt alles natürlich als root:

    Code:
    cd /usr/lib/hal
    mv hal-storage-mount hal-storage-mount.bin
    chattr +i hal-storage-mount.bin
    cp /tmp/hal-storage-mount .
    chmod 755 ./hal-storage-mount
    cp /tmp/50-usefree.fdi /etc/hal/fdi/policy
    /etc/init.d/haldaemon restart
    Mehr gibt es nicht zu tun. Platte anhängen und im KDE4 Device Notifier klicken - Open with File Manager - und die Platte ist mit "usefree" gemounted oder mit jeder andern Option, falls man eines der beiden Scripte und den fdi File anpasst.

    Ich hoffe Click wendet das Verfahren an und sagt wie es gegangen ist.

    Jetzt noch zum unseligen Beitrag von Schreibtroll. Er geht ja davon aus, dass Click und ich so dumm sind, dass wir laufend Wechselträger "abziehen und nicht abmelden". Er meint damit wohl unmounten. Das grenzt fast schon an Beleidigung. Wenn er keine Leseschwäche hätte, hätte er wohl gemerkt, dass zum Zeitpunkt wo er seinen Erguss verfasst hatte, Click schon verifiziert hat, dass der Freeze lediglich davon abhängig ist, ob mit usefree gemounted wird oder nicht. Falls er mal

    man 8 mount

    gemacht hätte, und nach "usefree" gesucht hätte, hätte er Folgendes gefunden:

    Code:
    usefree
                  Use the "free clusters" value stored on FSINFO. It'll be used
                  to determine number of free clusters
                  without  scanning  disk. But it's not used by default, because
                  recent Windows don't update it cor-
                  rectly in some case. If you are sure the "free clusters" on
                  FSINFO is correct, by this option  you
                  can avoid scanning disk.
    Daraus geht klar hervor, dass das Scanning ohne usefree immer gemacht wird, unabhängig von der Vorgeschichte des Wechselträgers.

    Schlimm ist aber, dass er von "längeren Mountzeiten" wegen dem schlechten Abziehen redet. Geradeso als würde das System noch schnell auf Kosten der "Mountzeit" einen Filesystem Check durchführen. Nun weiss aber jedes Kind, dass sich Unix im Falle eines korrupten Filessystems anders verhällt: - das Filesystem wird readonly gemountet und nicht die "Mountzeit verlängert".

    Leider verfügt ein VFAT Filesystem meines Erachtens über keine sogenannte Dirty-Flag. Das heisst, der Kernel kann nicht durch ledigliches Checken einer Flag im Superblock feststellen, dass das Filesystem dirty ist. Vielleicht hat Schreibtroll schon beobachtet, dass es bei korruptem Filesystem zum Einfrieren kommt, währenddem der Kernel IO macht. Dann friert übrigends alles ein - es gibt dann keine Komponenten auf dem Desktop, welche noch funktionieren. Vielleicht verwechselt er diese Geschichte mit unserer Scanning Problematik.

    So oder so ist es aber wichtig, dass wenn man VFAT Platten braucht und vor allem dann wenn man sie an Windowsrechner hängt, öfters mal

    fsck.vfat

    bemüht. Vor allem wenn man "usefree" benützt, kann man auf diese Art die Absicherung, welche man verliert kompensieren. Und damit schliesst sich der Kreis. Das Plasma Desktop auf Opensuse 11.2 friert übrigends während eines Filesystem Checks einer Platte nicht ein, auch nicht wenn es sich um eine VFAT Platte handelt.

  14. #14
    Registrierter Benutzer Avatar von Click
    Registriert seit
    Dec 2008
    Beiträge
    40
    Code:
    /dev/sdb1 on /media/BACKUPCLICK type vfat (rw,nosuid,nodev,uid=1000,utf8,shortname=mixed,flush,usefree)
    Wie du siehst hat alles genau so funktioniert, wie du es dir gedacht hast (und es auch logisch erscheint). Gemountet ist der Datenträger mit dem KDE4 Device Notifier und nicht per Hand.

    Ich bin dir sehr sehr dankbar, dass du deine Zeit investiert hast, dich so gründlich mit einem Problem wie diesem auseinanderzusetzen und ein Workaround zu entwickeln. Natürlich sollte dies nur ein Workaround bleiben und ich hoffe, dass die verantwortlichen Entwickler bald etwas gegen diesen Bug tun können.

    Du hast mir mit deinen Beiträgen - oder sollte ich Artikeln sagen? - sehr geholfen und ich hoffe und denke auch vielen anderen. Ich denke du kannst die Beschreibung des Workarounds nun auch im Bugreport veröffentlichen.

    Trotz deiner ganzen Mühen hätte ich noch eine Bitte: Poste hier doch bitte einen Link zu dem Bugreport, sodass sich hier alle den weiteren Verlauf des Bugs anschauen können und damit zu guter letzt auch die Chnace auf diesen Workaround/Bug zu stoßen größer wird. Immerhin ist dieser Bug wirklich nervig, wenn man mal "eben schnell" etwas auf einen VFAT Datenträger unter openSUSE 11.2 mit KDE4 kopieren möchte.

    Nocheinmal, Respekt und vielen Dank für deine Brmühungen.

    Manchmal sind Texte für "Wissenschaftler" dann doch besser, weil man ja weiß, dass es nicht einfach daran liegt, dass die Benutzer es vorziehen den "Wechseldatenträger manchmal einfach abzuziehen und nicht abzumelden".

    Also "Lange Rede kurzer Sinn..."
    Danke für diesen großartigen Workaround und für den Bugreport, chromium!
    und
    Ich hoffe das du hieran mal siehst, dass man nicht alle wie Idioten behandeln sollte und Probleme auch schon mal ernst sind, Schreibtroll.

  15. #15
    Registrierter Benutzer
    Registriert seit
    Jan 2010
    Beiträge
    8
    Ich werde den Link zum Bugreport ganz sicher liefern. Gib mir ein paar Tage Zeit. Ich melde mich spätestens am Wochenende.

Ähnliche Themen

  1. Pinnacle PCTV DVB-T nano USB-Stick 73e
    Von littletux2 im Forum Fernsehen
    Antworten: 34
    Letzter Beitrag: 28.08.09, 19:24
  2. Sound Blaster X-Fi beta Treiber
    Von ghettopuzzi im Forum Musik
    Antworten: 129
    Letzter Beitrag: 28.06.09, 22:18
  3. Tastatur spinnt
    Von dehein2 im Forum System installieren und konfigurieren
    Antworten: 5
    Letzter Beitrag: 05.08.08, 15:12
  4. Externe ext3 Patition kann nicht gemountet werden: Bad Superblock
    Von [HO]Xerxes im Forum System installieren und konfigurieren
    Antworten: 13
    Letzter Beitrag: 31.05.06, 20:53
  5. USB Kartenleser/Hub: usb-storage Devicescan Problem
    Von Skipper im Forum stationäre Hardware
    Antworten: 1
    Letzter Beitrag: 22.05.05, 14:53

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •