Re: [RFR] man://manpages-de/man2/fcntl.2.po (Teil 6)

[Chris Leick <c.leick@vollbio.de>]

Hallo Helge,

> #. type: Plain text
> msgid ""
> "The original Linux B<fcntl>()  system call was not designed to handle 
> large "
> "file offsets (in the I<flock> structure).  Consequently, an 
> B<fcntl64>()  "
> "system call was added in Linux 2.4.  The newer system call employs a "
> "different structure for file locking, I<flock64>, and corresponding "
> "commands, B<F_GETLK64>, B<F_SETLK64>, and B<F_SETLKW64>.  However, 
> these "
> "details can be ignored by applications using glibc, whose B<fcntl>()  "
> "wrapper function transparently employs the more recent system call 
> where it "
> "is available."
> msgstr ""
> "Der ursprüngliche Systemaufruf B<fcntl>() von Linux war nicht dafür "
> "konstruiert, große Dateiversätze (in der Struktur I<flock>) zu 
> handhaben. "
> "Konsequenterweise wurde ein Systemaufruf B<fcntl64>() in Linux 2.4 "
> "hinzugefügt. Dieser neuere Systemaufruf setzt eine andere Struktur zum "
> "Sperren von Dateien ein, I<flock64>, und entsprechende Befehle 
> B<F_GETLK64>, "
> "B<F_SETLK64> und B<F_SETLKW64>. Diese Details könne allerdings von "
> "Anwendungen, die Glibc einsetzen, ignoriert werden, da dessen "
> "Wrapperfunktion B<fcntl>() transparent den neueren Systemaufruf 
> einsetzt, wo "
> "er verfügbar ist."

s/könne/können/


> #.  commit ef1820f9be27b6ad158f433ab38002ab8131db4d
> #.  commit f6de7a39c181dfb8a2c534661a53c73afb3081cd
> #. type: Plain text
> msgid ""
> "Since Linux 3.12, if an NFSv4 client loses contact with the server, 
> any I/O "
> "to the file by a process which \"thinks\" it holds a lock will fail 
> until "
> "that process closes and reopens the file.  A kernel parameter, I<nfs."
> "recover_lost_locks>, can be set to 1 to obtain the pre-3.12 behavior, "
> "whereby the client will attempt to recover lost locks when contact is "
> "reestablished with the server.  Because of the attendant risk of data "
> "corruption, this parameter defaults to 0 (disabled)."
> msgstr ""
> "Wenn seit Linux 3.12 ein NFSv4-Client den Kontakt mit dem Server 
> verliert, "
> "wird jede E/A des Prozesses, der »glaubt«, er halte eine Sperre, "
> "fehlschlagen, bis dieser Prozess die Datei schließt und erneut 
> öffnet. Ein "
> "Kernelparameter (I<nfs.recover_lost_locks>) kann auf 1 gesetzt 
> werden, um "
> "das pre-3.12-Verhalten zu errreichen, bei dem ein Client versuchen 
> wird, "
> "verloren gegangene Sperren wiederherzustellen, wenn der Kontakt mit dem "
> "Server wieder etabliert ist. Aufgrund des vorhandenen Risikos der "
> "Datenverfälschung ist die Vorgabe für diesen Parameter 0 (deaktiviert)."

s/errreichen/erreichen/


> #. type: Plain text
> msgid ""
> "The Linux implementation of mandatory locking is subject to race 
> conditions "
> "which render it unreliable: a B<write>(2)  call that overlaps with a 
> lock "
> "may modify data after the mandatory lock is acquired; a B<read>(2)  
> call "
> "that overlaps with a lock may detect changes to data that were made 
> only "
> "after a write lock was acquired.  Similar races exist between mandatory "
> "locks and B<mmap>(2).  It is therefore inadvisable to rely on mandatory "
> "locking."
> msgstr ""

Die Linux-Implementierung zwangsläufiger Sperren ist Gegenstand von 
Ressourcenwettläufen, die sie unzuverlässig machen: Ein 
B<write>(2)-Aufruf, der sich mit einer Sperre überschneidet, kann Daten 
verändern, nachdem die zwangsläufige Sperre erlangt wurde. Ein 
B<read>(2)-Aufruf, der sich mit einer Sperre überschneidet, kann 
Änderungen an Daten entdecken, die nur vorgenommen werden, nachdem eine 
Schreibsperre erlangt wurde. Ähnliche Wettläufe gibt es zwischen 
zwangsläufigen Sperren und B<mmap>(2). Daher ist es nicht zu empfehlen, 
sich auf zwangsläufige Sperren zu verlassen.

Gruß,
Chris