usbstick ohne umount entfernt - probleme

[Basti_litho]

Hallo,

wenn ich meinen USB-Stick - ohne ihn auszuhängen (umount) - entferne, habe ich mehrere Probleme:

1. ich kann ihn mehr benutzen - mount/umount beenden sich mit fehlermeldungen. D.h. ich kann ihn nicht ein- oder aushängen.

Wenn ich ihn runterfahre fährt er nicht ganz runter sondern bleibt mit folgender Meldung stehen:

g_vfs_done():da0s1[WRITE(offset=16384, length=4096)]error = 6

Das wiederholt er jede Sekunde wieder - aber mehr macht er auch nicht.

Weiß jemand wie man einen nicht mehr vorhandenen stick aus dem System abzumelden?

Unter

 

[Yamagi]

Vermutlich ist das Dateisystem auf dem Stick hinüber. Bei einigen Modellen kann man es per Knopfdruck neu erzeugen, ansonsten musst du den Stick mittels dd nullen und per newfs_msdosfs das fs neu anlegen. Die Daten auf dem Teil gehen bei beiden Methoden natürlich verloren.

 

[ouTi]

device ohne umount zu entfernen ist ein klassischen beispiel für: "How to shoot yourself in the foot"

atm gibt es hierfür nur eine lösung: "don't do it!"

 

[cheasy]

Hallo,

wenn ich meinen USB-Stick - ohne ihn auszuhängen (umount) - entferne, habe ich mehrere Probleme:

1. ich kann ihn mehr benutzen - mount/umount beenden sich mit fehlermeldungen. D.h. ich kann ihn nicht ein- oder aushängen.

Das Filesystem auf dem Stick ist inkonsistent und muss repariert werden. Fur FFS und UFS macht dies fsck. DOS-Filesystem weiss ich nicht, jedoch sollte das mit Windoof irgendwie gehen.

Wenn ich ihn runterfahre fährt er nicht ganz runter sondern bleibt mit folgender Meldung stehen:

g_vfs_done():da0s1[WRITE(offset=16384, length=4096)]error = 6

Das wiederholt er jede Sekunde wieder - aber mehr macht er auch nicht.

Das System versucht, die auf dem USB-Stick fehlenden Teile des Filesystems auf diesen zu schreiben, bevor sie aus Strommangel verloren gehen. Das geht nicht, weil der Stick weg ist. Deshalb geht das System nicht aus.

Weiß jemand wie man einen nicht mehr vorhandenen stick aus dem System abzumelden?

Das ist so nicht gewünscht. Datenverlust erfordert immer eine Operator-Interaktion -- in diesem Fall manuelles Ausschalten des Systems.

 

[Basti_litho]

Also der USB-Stick bzw. das Filesystem ist nicht beschädigt - wenn ich den Rechner neu gestartet habe, funktioniert er tadellos.

 

[soul_rebel]

hab mal ähnliche probleme gehabt, hatte einen laptop mit usb2 festplatte in nem land wo andauernd der strom ausfiel.
die festplatte hat sich direkt verabschiedet, während das system auf baterie betrieb umschaltete. als ich ein umount des geräts versucht habe (um probleme beim runterfahren zu vermeiden), ist die kernel sofort abgeschmiert und das ding hat neugestartet.

atm gibt es hierfür nur eine lösung: "don't do it!"

ist ja echt komisch, ich glaube nciht dass jemand zum spass den stick immer weiter reinsteckt und rauszieht
und ich bin schon der meinung, dass ein system damit umgehen können muss, wenn ein gemountetes device entfernt wird...

 

[Basti_litho]

und ich bin schon der meinung, dass ein system damit umgehen können muss, wenn ein gemountetes device entfernt wird...

ja, eben - dachte ich auch mies wenn das nicht so ist.

Irgendwie muss man dem Kernel doch mitteilen können das das Gerät nicht mehr vorhanden ist.

g_vfs_done():da0s1[WRITE(offset=16384, length=4096)]error = 6

Das System versucht, die auf dem USB-Stick fehlenden Teile des Filesystems auf diesen zu schreiben...

Hilft es (kann es grade nicht ausprobieren) wenn man den usb-stick als "sync" mountet? Oder gibt es sonst noch irgendeine Einstellung die man vornehmen kann?

Wenn ich den stick mounte (sonst nichts mache) und ihn rausziehe - kommt ja die selbe Fehlermeldung - aber er sollte ja eigentlich nichts schreiben - hab ja nichts angeforder.

Gruß,
Basti_litho

 

[marzl]

Ich kann es im Moment nicht ausprobieren, aber folgende Bedingungen müssen theoretisch gegeben sein, damit es klappt (Linux bekommt das ja auch hin)

1. es MUSS bei solchen "Wechseldatenträgern" der Schreibcache deaktiviert sein
2. das mount und unmount sollte über die devd.conf geregelt sein. Besonders das umount muss dann wohl über -f (force) erzwungen werden.

Wenn der Kernel das mitmacht, sollte es klappen.

 

[Basti_litho]

ja, super - werde ich gleich wenn ich wieder kann ausprobieren.

Aber: wie kann das umounten über den devd geregelt werden.
Ich weiß das er bei einem "detatch" (o.ä.) was unternehmen kann - aber dann ist der stick ja schon weg. (meinst du dann mit "mount -f..." erzwingen?)

 

[kili]

1. ich kann ihn mehr benutzen - mount/umount beenden sich mit fehlermeldungen. D.h. ich kann ihn nicht ein- oder aushängen.

Wild guess: umount -f als Notloesung.

Ich kenne allerdings FreeBSD nicht.

 

[Basti_litho]

Wild guess: umount -f als Notloesung.

Ich kenne allerdings FreeBSD nicht.

Das hat ja auch marzl vorgeschlagen.

Hat aber auch nicht geholfen:

FreeBSD hat gleich einen sauberen Neustart hingelegt (ohne nachfrage - frechheit )

naja, schade.

Gruß
Basti

 

[kili]

Das hat ja auch marzl vorgeschlagen.

Das hatte ich uebersehen. Sorry.

BTW: Ich habe eben zum Spass mal einen Memorystick in mein Soekris mit OpenBSD gesteckt, gemounted und waehrend einer laengeren Schreiboperation wieder rausgezogen. Danach hing sowohl ein ls auf dem Mountpoint als auch ein shutdown -r now. Aber lt. mount war das Teil nicht mehr gemounted. Ich bin gerade zu faul, hier jetzt herumzukabeln, aber wenn ich morgen Langeweile habe, werde ich das mal debuggen.

 

[Basti_litho]

ich hab ja noch nichtmal einen Schreibvorgang vorgenommen.
Es reicht das ich ihn mounte. Und dann ohne umount rausziehe.

Ja, wäre wirklich mal interessant wie die das gelöst haben. *hoffnung*

Gruß
Basti

 

[juedan]

Moin,

das scheint ein generelles Problem von FreeBSD zu sein:
ein versehentliches Entnehmen einer Diskette, USB-Sticks oder sonstigen "nicht hardware lockbaren" Datenträgers erzeugt komischerweise fast immer einen Kernel-Panic. Das habe ich schon auf mehreren FBSD-Plattformen und -Versionen beobachten können. Vielleicht sollten sich die Entwickler mal ansehen, wie es in OpenSolaris gelöst ist. Da habe ich solche Schwierigkeiten noch nicht erlebt.
Das war jetzt eine kleine Kritik am Entwicklerteam - ich ducke mich auch schon weg.

Viele Grüße

Jürgen

 

[ouTi]

dies problem ist schon seit ewigkeiten bekannt allerdings nicht einfach zu lösen. mehr infos hierzu gibts auf den mailinglists.

 

[dettus]

bei usb-sticks etc ist es imho am allerallerallerbesten den mount-befehl wegzulassen.
und die mtools zu benutzen.

einfach eine /etc/mtools.conf anlegen:

drive a: file="/dev/fd0"
drive b: file="/dev/da0s1"

und dann mit

% mdir b:
% mcp * b:
% mmkdir b:bla
% mcd b:bla
% mdel b:blubb.txt

arbeiten.

 

[0815Chaot]

Das Filesystem auf dem Stick ist inkonsistent und muss repariert werden. Fur FFS und UFS macht dies fsck. DOS-Filesystem weiss ich nicht, jedoch sollte das mit Windoof irgendwie gehen.

Oder mit fsck_msdosfs(8).

Allgemein zum Thema:

Wenn dem Kernel ein Dateisystem unter dem Hintern weggezogen wird, sollte IMO ein sofortiger Kernel Panic die Folge sein. Bei einem USB-Stick mit unwichtigen Daten mag euch das egal sein. Der Kernel kann aber nicht entscheiden, ob die Daten auf dem Dateisystem wichtig sind oder nicht. Im Prinzip ist der USB-Stick für den Kernel eine SCSI-Festplatte wie jede andere auch. Stellt euch z.B. mal vor, der Datenträger wäre eine Wechselfestplatte, auf die ihr gerade eurer wöchentliches Vollbackup schreiben lasst. Wenn mir das wegbricht, möchte ich aber eine sofortige Panic sehen. Die Daten einfach wegzuschmeissen, weil das Dateisystem halt irgendwie nicht mehr da ist, wäre falsch. YMMV. Kann man also so oder so sehen.

Aber im Grunde ist ein Hardwarefehler ein Hardwarefehler und kann eher selten durch Software korrigiert werden. In solchen Fällen ist ein Kernel Panic durchaus angebracht, wenn der Fehler denn durch den Kernel erkannt werden kann.

Der Vorschlag von dettus ist für unwichtige Daten eigentlich nicht schlecht. Sofern man darauf achtet, den Schreib-Cache des Sticks zu deaktivieren, sollte das funktionieren. Natürlich hat man dann immer noch das gleiche Problem mit der Dateninkonsistenz auf dem Stick, sollte man ihn während einer Schreiboperation abziehen. Damit hat dann aber wenigstens der Kernel kein Problem, weil die mtools direkt auf das Device zugreifen, Error Handling ist dann allein deren Sache.

 

[marzl]

das ist ja alles richtig und technisch korrekt, aber wenig praktikabel für den anwender.
unter linux, windows und gott wer weiss wo geht das ja auch, ohne das direkt alles kaputt geht oder der kernel wegspringt. mal davon abgesehen, das usb exakt für solche aufgaben geschaffen wurde (hot plug'n'play).
also ich stehe auf der seite die ein möglichst einfaches datenträgerhändling ermöglichen möchte, ohne das *bsd rumzickt

 

[0815Chaot]

Natürlich kommt bei sowas immer: "Aber XY macht das so." Windows weist den im Setup angelegten Benutzern Administrator-Rechte zu. Linux hat (hatte?) schon einen Webserver im Kernel. Kann man gut oder schlecht finden, ist aber nicht wirklich ein Argument dafür, wie man es "korrekt" handhaben sollte. Natürlich kann man darüber diskutieren, aber doch bitte nicht mit: "XY macht das so." Vielleicht sollte man dabei auch die verschiedenen Zielgruppen der einzelnen Systeme bedenken. Bei Windows soll alles für den Anwender möglichst einfach sein, an allen Ecken und Enden wird man mit Dialog-Boxen bemuttert. Bei FreeBSD wünsche ich mir aber eher eine technisch korrekte Implementierung, die root das tun lässt, was root tun will, und dann eben die technisch korrekte Quittung liefert.

Aber ich habe selbst schon erlebt, daß man auch unter Windows auf "Gerät abmelden" (oder wie das Teil in der Taskleiste auch immer heißt) klicken sollte, bevor man den Stick abzieht. Als ich bei einem Bekannten war, hatte er mir ein paar PDFs auf meinen Stick kopiert und das Teil dann einfach abgezogen, nachdem der Kopieren-Fortschritts-Dialog (heißt der unter Windows so?) verschwunden war. Er war wohl auch der Meinung, daß das kein Problem sei. Folge: Als ich zuhause ankam, waren nur zwei der ca. zehn PDFs auf meinem Stick. Darüber wäre ich gerne schon vorher informiert worden...

Ich stehe halt auf der Seite, daß Datenträger-Handling zuverlässig sein muß. Dazu gehört auch irgendwie Zuverlässigkeit bei dem, der das Teil mountet. Das darf ja auch nicht jeder, sondern im "Auslieferungszustand" nur root. Und auf den muß man sich ja noch irgendwie verlassen können. Ein root unter FreeBSD ist doch was anderes als ein Administrator unter Windows. Und wenn sich root eben unbedingt in den Fuß schießen will - nur zu. Es gibt halt Dinge, die sollte man nicht tun, und wenn man's doch macht, gibt es eben die technisch korrekte Antwort - das kann auch ein Kernel Panic sein. Ich liebe technisch direkte Betriebssysteme.

Im Übrigen heißt "Hot Plug" auch nur, daß Geräte im laufenden Betrieb vom Bus an- und abgemeldet werden können, nichts weiter. Damit ist nicht gemeint, daß man Geräte munter abziehen sollte, wenn sie in Benutzung sind. Ein gemountetes Dateisystem ist ganz klar in Benutzung, zu jeder Zeit, solange es gemountet ist.

 

[marzl]

Im Übrigen heißt "Hot Plug" auch nur, daß Geräte im laufenden Betrieb vom Bus an- und abgemeldet werden können, nichts weiter. Damit ist nicht gemeint, daß man Geräte munter abziehen sollte, wenn sie in Benutzung sind. Ein gemountetes Dateisystem ist ganz klar in Benutzung, zu jeder Zeit, solange es gemountet ist.

ja, hast ja eigentlich recht gemounted = in benutzung da stimmt ich dir 100% zu. trotz allem wäre es irgendwie "schön", wenn grade bei bestimmten geräten etwas mehr "dynamik" ins spiel kommen könnte.
vielleicht kann man nochwas mit dem automounter drehen und wenden. muss ich mich bei gelegenheit nochmal hinterklemmen. irgendeine kombination wird dann schon rauskommen

 

[cheasy]

Irgendwie muss man dem Kernel doch mitteilen können das das Gerät nicht mehr vorhanden ist.

Nein. Das Konzept sieht keinen Wechselmassenspeicher vor. Das ist auch der Grund, warum CD-ROMs im zugriff nicht ausgeworfen werden.

Hilft es (kann es grade nicht ausprobieren) wenn man den usb-stick als "sync" mountet?

Nein.

Oder gibt es sonst noch irgendeine Einstellung die man vornehmen kann?

Du kannst den Stick read only mounten.

Wenn ich den stick mounte (sonst nichts mache) und ihn rausziehe - kommt ja die selbe Fehlermeldung - aber er sollte ja eigentlich nichts schreiben - hab ja nichts angeforder.

Du hast den Stick gemountet, damit wird mindestens das Dirty-Flag geschrieben. Auch werden bei Lesezugriffen die Filesytem-Metadaten aktualisiert und müssen deshalb auch geschrieben werden.

 

[0815Chaot]

vielleicht kann man nochwas mit dem automounter drehen und wenden. muss ich mich bei gelegenheit nochmal hinterklemmen. irgendeine kombination wird dann schon rauskommen

Man könnte natürlich mit automount(8) nach relativ kurzer Inaktivität unmounten lassen. Der Benutzer müßte nur sehen können, ob sein Stick momentan unmountet ist, weil er im nächsten Moment ja wieder automatisch gemountet werden könnte, wenn irgendwer darauf zugreifen will. Programme wie KwikDisk/KDiskFree unter KDE sollten das "in Echtzeit" anzeigen können, ansonsten kann man auch mount(8) per Skript anquatschen. Eine gewisse Koordinationsfähigkeit des Benutzers vorausgesetzt, sollte das auf einem Ein-Benutzer-System durchaus funktionieren. Aber mal im Ernst: Solche Leute sollten dann auch in der Lage sein, direkt umount(8) bedarfsgerecht zu verwenden.

Probleme gibt es aber, wenn automount nicht zum Unmounten kommt. Ein Gerät ist ja schon in Benutzung, wenn das aktuelle Arbeitsverzeichnis irgendeines Prozesses auf dem Stick liegt. Gerade graphische Datei-Manager neigen dazu, einmal besuchte Verzeichnisse zwecks Performancesteigerung "offen" zu halten. Dann muß man den Datei-Manager im Zweifel komplett schließen, damit er den Stick endlich in Ruhe läßt.

Gegen Leute, die einen gemounteten Datenträger einfach so abziehen, kommst du damit aber auch nicht an.

Fazit: Mounten ist Vertrauenssache.

 

[Basti_litho]

Also ich habe das Problem vorläufig mit dem amd (automounter) geregelt.

Nach dieser Anleitung:
http://wiki.unixboard.de/index.php/FreeBSD_-_Automount

Obwohl die Anleitung recht erklärungsarm war.

Aber nun mountet er den sick (devd.conf Einträge habe ich komplett entfernt) und umountet ihn mir nach ca. 3 Minuten nicht benutzt.

Da ich sowieso recht wenig mit Konqueror & Co. arbeite passt das.

 

[cheasy]

Solange irgendein Prozess in einem Verzeichnis des Sticks steht, wird der automounter den Stick nicht unmounten können. Insofern ist das leider auch kein besonders guter Schutz gegen unmount-Probleme wegen entfernten Speicherriegels.

Zum Trost: Windoof macht das genauso, und beschwert sich ebenfalls bitterlich, wenn es den Stick nicht mehr findet -- wenn man NTFS drauf hat.

 

[Basti_litho]

Naja, gut - aber immherin umountet er überhaupt.

Mit amd verringert sich einfach die wahrscheinlichkeit das man einen USB-Stick rauszieht während er noch gemountet ist.

Zu Windows: ja - er er schmiert nicht ab beim runterfahren. (zumindest bei fat)