A.3. Fsync

Fsync ist für seinen I/O-intensiven Betrieb bekannt, aber das ist nur die halbe Wahrheit. Werfen Sie beispielsweise einen Blick auf Theodore Ts'o's Artikel Don't fear the fsync! ^[5] und die dazugehörige Diskussion.

Firefox rief bisher die sqlite-Bibliothek bei jedem Aufruf einer neuen Seite durch den Benutzer auf. Sqlite rief fsync auf und aufgrund der Einstellungen des Dateisystems (hauptsächlich ext3 mit data-ordered Modus) entstand eine hohe Latenz bei Inaktivität. Dies konnte lange dauern (bis zu 30 Sekunden), wenn ein andere Prozess eine große Datei zur selben Zeit kopierte.

Bei anderen Fällen jedoch, bei denen fsync überhaupt nicht benutzt wurde, traten Probleme mit dem Wechsel zum ext4-Dateisystem auf. Ext3 war auf data-ordered Modus gesetzt, der den Speicher alle paar Sekunden löschte und auf Platte speicherte. Mit ext4 jedoch und laptop_mode, wurde das Intervall zwischen Speicherungen länger und Daten konnten verloren gehen, wenn das System unerwartet ausgeschaltet wurde. Auch wenn ext4 nun gepatcht ist, müssen wir das Design unserer Anwendungen nach wie vor vorsichtig überdenken und fsync verwenden, wo es angebracht ist.

Das nachfolgende, einfache Beispiel für das Lesen und das Schreiben in eine Konfigurationsdatei zeigt, wie eine Sicherung einer Datei erstellt werden kann, oder wie Daten verloren gehen können:

/* open and read configuration file e.g. ~/.kde/myconfig */
fd = open("./kde/myconfig", O_WRONLY|O_TRUNC|O_CREAT);
read(myconfig);
...
write(fd, bufferOfNewData, sizeof(bufferOfNewData));
close(fd);

Ein besserer Ansatz wäre:

open("/.kde/myconfig", O_WRONLY|O_TRUNC|O_CREAT);
read(myconfig);
...
fd = open("/.kde/myconfig.suffix", O_WRONLY|O_TRUNC|O_CREAT);
write(fd, bufferOfNewData, sizeof(bufferOfNewData));
fsync; /* paranoia - optional */
...
close(fd);
rename("/.kde/myconfig", "/.kde/myconfig~"); /* paranoia - optional */
rename("/.kde/myconfig.suffix", "/.kde/myconfig");