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.
Lesezeichen