Re: Merkwürdiges geht vor in Version 9..

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Thu, 19 Jan 2012 18:07:41 +0100 (CET)

Marc Santhoff wrote:
> Am Donnerstag, den 19.01.2012, 13:06 +0100 schrieb Heino Tiedemann:
> > Polytropon <freebsd(at)edvax.de> wrote:
> > > Wenn's "nur" eine Sache von "CWD irgendwo im USB-Mount"
> > > ist, kann man getrost "umount -f" anwenden. Kritisch wird
> > > das, wenn Dateien noch irgendwo offen sind oder gar noch
> > > Schreibvorgänge ausstehen.
> >
> > cooler tipp mit dem "-f".
> >
> > wenn man weiss, das da nix mehr geschreiben werden muss...
>
> Ansosnsten gibt es noch sync(8), damit kann man sicher sein.

Eigentlich nicht. sync(8) ist ein homöopatisches Kommando.
In der Praxis ist es meistens ein Placebo und hat nur einen
rein mentalen Effekt. Es gibt nur ganz wenige Fälle, wo es
tatsächlich sinnvoll benutzt werden kann, aber dies ist
keiner davon.

> Gab es da nicht eine Regel, daß man es drei mal benutzen muß, damit
> alles wirklich restlos geschrieben wird?

Das ist ein altes Zauber-Ritual. Funktioniert auch nur,
wenn man es dreimal nacheinander manuell eingibt (mit
<Enter> dazwischen), »sync;sync;sync« ist wirkungslos.
Und man muss sich dabei dreimal richtung Mond verneigen,
"Vimsalavim" sagen und einen Tropfen Pinguinblut auf die
F8-Taste träufeln.

Genaugenommen triggert sync(8) nur den Syncer-Thread im
Kernel. Das ist genau der gleiche Mechanismus, der beim
Herunterfahren »Syncing disks:« und dann ein paar wilde
Zahlen ausgibt. Wie häufig man sync eingibt, ist relativ
egal. Eine Garantie, dass alle Buffer geschrieben sind,
hat man auch nach dem zehnten Mal nicht.

Und wenn doch noch irgendein Programm auf das Dateisystem
zugreift, ist es ohnehin für die Katz, weil man dann sofort
neue »Dirty-buffer« hat, die noch nicht geschrieben sind.
Es genügt sogar ein harmloses "ls", um einen Dirty-buffer
zu erzeugen, nämlich aufgrund des atime-Updates auf dem
Verzeichnis.

In dem speziellen Fall, um den es hier geht, ist sync(8)
sogar vollkommen nutzlos. Denn das umount -f sorgt
selbstverständlich dafür, dass alles geschrieben wird,
wie bei einem normalen umount. Die Option -f verhindert
das Syncen nicht, sondern sorgt nur dafür, dass offene
Dateien ignoriert werden, die sonst zur Meldung »device
busy« und dem Fehlschlagen des umount führen. Die
betreffenden Prozesse bekommen dann beim nächsten Zugriff
einen I/O-Fehler gemeldet (womit die meisten Programme
erfahrungsgemäß nicht sinnvoll umgehen können), aber alle
Dirty-buffer werden gesynct, das clean-Flag wird gesetzt,
und das Dateisystem ist anschließend in einem konsistenten
Zustand.

Wer sich mit sync(8) besser fühlt, kann es natürlich gerne
benutzen, aber einen real messbaren Effekt hat es nicht.
Eben wie ein homöopathisches Arzneimittel.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"C++ is to C as Lung Cancer is to Lung."
        -- Thomas Funke
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 19 Jan 2012 - 18:08:03 CET

search this site