Re: /kernel: handle_workitem_freeblocks

From: Simon 'corecode' Schubert <corecode(at)corecode.ath.cx>
Date: Tue, 21 May 2002 22:50:35 -0700

Oliver Fromme <olli(at)secnetix.de> wrote:
> Wenn Du jetzt ein »echo "" > Logdatei« machst, dann macht
> die Shell zuerst ein truncate() auf die Datei, um sie auf
> 0 Bytes zu kürzen, dann erzeugt das »echo ""« ein Newline,
> das an den Anfang der Datei geschrieben wird. Theoretisch
> müßte die Datei jetzt ein Byte groß sein (eine Leerzeile).
>
> Das alles kümmert aber unseren Prozeß nicht, der die Datei
> immer noch geöffnet hält. Weder das truncate() noch der
> Schreibzugriff durch das echo haben an seinem Handle etwas
> geändert (logisch), und sein Filepointer zeigt immer noch
> an die alte Position. Wenn jetzt dieser Prozeß eine wei-
> tere Zeile in das Logfile schreibt, landet diese nicht
> etwa an Byte 1 (hinter dem Newline), sondern natürlich
> dort, wo sein Filepointer (immer noch) hinzeigt, irgendwo
> weiter hinten. Zwischen Byte 1 und dieser Schreibposition
> entsteht eine Lücke.

das ist nur bedingt richtig. ein gut geschriebenes program wird log files grundsaetzlich mit ``append'' flag oeffnen. dann stoeren sich naemlich auch 2 prozesse nicht, die gleichzeitig in die datei reinschreiben (auch zb. durch fork() erzeugte kinder).
dieses append bewirkt (wie du sicherlich weisst, aber zur allgemeinen aufklaerung ;]), dass vor jedem write() techisch ein seek ans ende der datei geschieht. dies ist aber im gegensatz zu einem userland seek() und write() atomar, dh. es entsteht keine race condition: jede geschriebene zeile (oder daten) werden immer an das ende geschrieben.

wenn nun ein anderer prozess diese datei abschneidet, dann wird diese ja kuerzer (logisch!). schreibt dannach ein prozess, der die datei mit O_APPEND geoeffnet haellt, so haengt der die daten direkt ans ende, welches ja ganz vorne, also in dem fall bei byte 1, liegt.

anders verhaellt es sich natuerlich wenn der prozess icht mit O_APPEND arbeitet sondern einfach vor sich her schreibt ("wird schon niemand an der datei rumarbeiten"). dann entsteht das szenario welches du geschildert hast.

gruesse
  simon

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 21 May 2002 - 22:51:33 CEST

search this site