Re: konkurrierende Dateizugriffe

Marc Santhoff <M.Santhoff(at)t-online.de> wrote:
> Am Mo, den 07.03.2005 schrieb Oliver Fromme um 16:33:
> [...]
> > Nein, natürlich dürfen auch andere Prozesse schreiben. In
> > obigem konkreten Beispiel haben _beide_ Prozesse schreibend
> > auf die Datei zugegriffen: Ich hatte den Header der tar-
> > Datei mit einem Hex-Editor verändert, während (gleichzei-
> > tig) der tar-Prozeß noch in die Datei reinschrieb. Es gab
> > keinen Grund, darauf zu warten, bis der fertig ist.
> >
> > Daß man beim Arbeiten durch unnötige Mechanismen behindert
> > wird, ist ja auch eher eine Windows-Domäne. ;-)
>
> Wahrscheinlich ist das auch der Grund für die unterschiedlichen
> Auffassungen: Windows ist für einen grundlegend anderen Zweck geschaffen
> als das Basissystem von FreeBSD.

Das kommt auf den Standpunkt an. Sowohl bei UNIX als auch
bei Windows sollte der »Kernel« prinzipiell kooperative
(Schreib-)Zugriffe mehrerer Prozesse auf dieselbe Datei
zulassen und APIs zur Verfügung stellen, die dies unter-
stützen. Schließlich wird auch Windows als Multitasking-
System bezeichnet (auch wenn mir in konkreten Situationen
zuweilen Zweifel daran kommen).

> Bei den üblichen binären proprietären Formaten vieler Programme aus der
> Anwendungsdomäne (das übliche halt, alles was mit "Office" gemeint ist -
> nicht nur von Microsoft sondern auch alle anderen auf Windows, Corel,
> Autodesk, usw.) ist es normalerweise ein Problem, wenn mehrere Instanzen
> des Programms auf eine Datei gleichzeitig schreibend zugreifen.

Wenn das Dateiformat und/oder die Zugriffsprotokolle nicht
für konkurrierende Zugriffe geeignet sind, dann sollte die
Anwendung für ein geeignetes Locking sorgen. Bei »Office«
ist das meines Wissens auch der Fall.

Es wäre natürlich geschickter und praktischer, das Datei-
format und die Zugriffsprotokolle so zu designen, daß kon-
kurrierende Zugriffe gemacht werden können. Dafür, daß das
prinzipiell möglich ist, gibt es ja diverse Beispiele (und
die müssen nicht gleich so komplexe sein wie ein Datenbank-
system).

Übrigens erlauben die APIs von lockf(3) und fcntl(2), Teil-
bereiche einer Datei zu locken (das flock(2)-Interface da-
gegen kann immer nur die ganze Datei locken). Somit ist es
möglich, daß ein Prozeß nur den Bereich sperrt, in dem er
gerade herumprokelt, während der Rest der Datei von anderen
Prozessen bearbeitet werden kann. Darüberhinaus kann man
auch per IPC ein eigenes Locking-Protokoll implementieren,
und es gibt weitere Möglichkeiten (z.B. per Semaphoren in
der Datei selbst).

Praktisch ist auch, daß man sich per mmap(2) einen Teil ei-
ner Datei (oder auch eine ganze Datei) in den Speicher map-
pen und dann so darauf zugreifen kann, als sei es normaler
RAM-Speicher. Auch das ist konkurrierend durch mehrere
Prozesse zugleich möglich, und es gibt ein spezielles Flag
(»MAP_SHARED«), das bewirkt, daß Änderungen durch Schreib-
zugriffe für alle anderen Prozesse sofort sichtbar sind.
Dies kann als Alternative zu SysV-ShMem (shmget(2)) genutzt
werden, um Shared-Memory zu erhalten.

(Das alles und noch viel mehr ist ausführlichst bei Stevens
nachzulesen.)

> Allerdings muß das vom Dateisystem abhängen, denn der Inhalt von
> tar-Archiven ist ja auch nicht immer nur Text.

Das ist eigentlich völlig unerheblich.

> Unter FreeBSD wird das anders gehandhabt, das finde ich ziemlich
> interessant. Da ich aus Zeitmangel die Grundlagen aber noch nicht
> gelesen habe, kann ich nur spekulieren: UFS/FFS fängt konkurrierende
> Zugriffe auf die selbe Zuordnungseinheit sicher ab? Es macht den
> Eindruck ...

Jein. Parallel stattfindende Schreibzugriffe werden früher
oder später serialisiert. Selbst auf einem Multiprozessor-
system können zwei Schreibzugriffe nicht wirklich gleich-
zeitig stattfinden; einer von beiden wird immer der erste
sein. Und wenn dann gleich der zweite Schribzugriff folgt,
werden die Daten des ersten natürlich wieder überschrieben.

Ob das gewollt ist oder nicht (bzw. ob es einen Schaden an-
richten kann oder nicht), ist Anwendungssache. Der Kernel
bzw. der UFS-Treiber kann und darf darüber nicht entschei-
den.

> Du sagst also, den Fall der Dateikorruption durch gleichzeitige
> schreibende Zugriffe kann es auf FreeBSD nicht geben?

Moment -- Es ging um Dateisystemkorruption. Die kann tat-
sächlich nicht passieren.

Dateikorruption kann natürlich passieren; dazu braucht man
nichtmal gleichzeitig zugreifende Prozesse. Dafür genügt
schon ein Prozess, der Müll in eine Datei schreibt.
;-)

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
Passwords are like underwear.  You don't share them,
you don't hang them on your monitor or under your keyboard,
you don't email them, or put them on a web site,
and you must change them very often.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message