Re: USB Sticks unmounten
On 05.01.06 19:24:12, Gerhard Wolfstieg wrote:
> On Thu, 5 Jan 2006 18:47:24 +0100
> Andreas Pakulat <apaku@gmx.de> wrote:
>
> > > An der Struktur der Daten auf den Medien kann es doch nicht liegen.
> > > Es ist denkbar, daß der Kernwel/die Mernelmodule erst die Daten und
> > > dann die inode-Infos schreiben. Dadurch passiert in dem Fall auch
> > > beim abrupten Abziehen eines sticks nix -- wenn nicht gerade in der
> > > µsec inodes beschrieben werden.
> >
> > Ich verstehe nicht ganz worauf du hinauswillst. synchrones Schreiben
> > bedeutet das alle Daten sofort geschrieben werden, asynchron bedeutet
> > das die Daten erst geschrieben werden wenn der Kernel grad nichts
> > besseres zu tun hat. Wenn du zwischen dem "cp" und dem eigentlichen
> > Schreiben der Daten den Stick abziehst wird nichts geschrieben. Das
> > gilt auch fuer ext2/3. Wie gesagt ich mag mich irren, aber ext2/3 sind
> > wohl die einzigen FS die synchrones Schreiben korrekt implementieren,
> > frag mich aber bitte nicht wie das genau aussieht bzw. wo der
> > Unterschied zu einem sync-gemounteten vfat ist.
>
> Wenn ein Dateisystem die Definition der Strukturen auf den Medien ist
> und sonst nichts, kann ein Dateisystem selbst die Art des Schreibens
> (synchron/asynchron) nicht bestimmen. Dafür müssen a priori Funktionen
> im Kernel zuständig sein und garantieren, daß das funktioniert. Bestimmt
> ext2/3 auch die Kernelfunktionen mit? Das ist die Frage.
Achso, sei doch nicht so genau ;-) Was hier gemeint ist ist nicht das
Dateisystem auf dem Medium, sondern die Kerneltreiber fuer das
Dateisystem. Wie gesagt ich finde leider die Stelle nicht an der ich das
gelesen habe (man mount sagt nur das einige Linux-FS sync nicht
unterstuetzen), aber vfat hat angeblich eben keine Unterstuetzung fuer
sync (also der Kerneltreiber, das Dateisystem ist in dem Fall ja FATXX).
ext2/3 haben Unterstuetzung, ich vermute das das dann so ablaeuft das
die write() Funktion prueft ob sync oder async und entsprechend andere
Code-Pfade ausgefuehrt werden und bei vfat gibts diese Unterscheidung
eben nicht.
Grad nochmal mit vfat getestet: Ein cp largefile /usbstick braucht ne
Weile:
andreas@morpheus:~>time cp temp/largefile /media/LG_USB\ DRIVE_usbstick/
time sync
real 0m27.639s
user 0m0.023s
sys 0m1.385s
andreas@morpheus:~>time sync
real 0m10.219s
user 0m0.001s
sys 0m0.289s
mit sync gemountet hab ich das kopieren abgebrochen, nach:
andreas@morpheus:~>time cp temp/largefile /media/LG_USB\ DRIVE_usbstick/
real 3m55.985s
user 0m0.006s
sys 0m0.520s
andreas@morpheus:~>ls -l temp/largefile
-rw-r--r-- 1 andreas andreas 208601854 2006-01-05 21:03 temp/largefile
Also duerfte das Problem bei vfat sein, dass er nach jedem Datenblock
erstmal die FAT neuschreiben muss wenn sync gemountet wird. Was dann
auch erklaert warum die Sticks nicht sehr langlebig sind wenn sie
sync-gemountet werden. Unter Windows wird sicher auch nicht sync
gemountet, deswegen darfst du ja auch dort Sticks nicht abziehen sondern
musst sie erst "abschalten" mittels Icon im Systray.
> > > Ich verstehe zum Beispiel auch nicht, warum es Samba gibt.
> >
> > Es wurde entwickelt um mit Windows-Rechnern Freigaben austauschen zu
> > koennen. Mittlerweile kann Samba aber ein wenig mehr als das.
>
> Es ist theoretisch -- sicher: wäre es nicht viel einfacher, das
> Handling der Freigaben und mehr in Richtung Linux-Rechner unter Windows
> zu bauen, weil u.A. die Probleme der nicht offenen "Standards" nicht
> existierten?
Vllt. aber solange sich kein Opensource-Entwickler fuer Windows
interessiert... Man kann einige Dinge uebrigens Ersetzen, auf Arbeit
laeuft die Anmeldung ueber Netware und die Verteilung von Applikationen
auch - dahinter steht ein LDAP-Verzeichnis. Verzeichnisfreigaben sind
aber trotzdem "Normale" Windows-Shares.
Andreas
--
Your lucky number is 3552664958674928. Watch for it everywhere.
Reply to: