{"id":98090,"date":"2020-10-24T02:42:38","date_gmt":"2020-10-24T00:42:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux"},"modified":"2020-11-18T00:58:48","modified_gmt":"2020-11-17T22:58:48","slug":"ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Nachhaltige Datenspeicherung und Linux-Datei-APIs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ich habe, w\u00e4hrend ich die Stabilit\u00e4t der Datenspeicherung in Cloud-Systemen untersuchte, beschlossen, mich selbst zu \u00fcberpr\u00fcfen und sicherzustellen, dass ich die grundlegenden Dinge verstehe. Ich begann mit dem Lesen der NVMe-Spezifikation<\/a><\/noindex> , um herauszufinden, welche Garantien hinsichtlich der stabilen Datenspeicherung (also die Garantie, dass die Daten nach einem Systemausfall verf\u00fcgbar sind) uns NVMe-Disks bieten. Ich habe die folgenden wesentlichen Erkenntnisse gewonnen: Daten sollten als besch\u00e4digt betrachtet werden, vom Zeitpunkt der Ausgabe des Schreibbefehls bis zum Abschluss des Schreibvorgangs auf das Speichermedium. In den meisten Datenaufzeichnungsprogrammen werden jedoch ganz normal Systemaufrufe verwendet.<\/p>\n

In diesem Material untersuche ich die Mechanismen der stabilen Datenspeicherung, die durch die Datei-APIs von Linux bereitgestellt werden. Es scheint, als sollte alles einfach sein: Das Programm ruft den Befehl write()<\/code>, und nachdem dieser Befehl abgeschlossen ist, sollten die Daten sicher auf der Festplatte gespeichert sein. Aber write()<\/code> kopiert lediglich die Anwendungsdaten in den Cache des Kernels, der sich im Hauptspeicher befindet. Um das System zum Schreiben der Daten auf die Festplatte zu zwingen, m\u00fcssen einige zus\u00e4tzliche Mechanismen verwendet werden.<\/p>\n

\"Nachhaltige<\/a><\/noindex><\/p>\n

Insgesamt stellt dieses Material eine Sammlung von Notizen zu dem dar, was ich \u00fcber das Thema, das mich interessiert, herausgefunden habe. Kurz gesagt: F\u00fcr die Organisation der stabilen Datenspeicherung sollte der Befehl fdatasync()<\/code> oder das \u00d6ffnen von Dateien mit dem Flag O_DSYNC<\/code>verwendet werden. Wenn Sie mehr \u00fcber die Details erfahren m\u00f6chten, was mit den Daten auf dem Weg vom Programmcode zur Festplatte passiert, schauen Sie sich die Maschine verwendet.<\/a><\/noindex> Artikel an.
\n<\/a><\/noindex><\/p>\n

Besonderheiten der Verwendung der Funktion write()<\/h2>\n

\nSystemaufruf write()<\/code> wird im Standard IEEE POSIX<\/a><\/noindex> definiert als ein Versuch, Daten in einen Dateideskriptor zu schreiben. Nach erfolgreichem Abschluss write()<\/code> sollten Datenlesevorg\u00e4nge genau die Bytes zur\u00fcckgeben, die vorher geschrieben wurden, selbst wenn auf die Daten aus anderen Prozessen oder Threads zugegriffen wird (hier<\/a><\/noindex> entsprechender Abschnitt des POSIX-Standards). Hier<\/a><\/noindex>, im Abschnitt \u00fcber die Interaktion von Threads mit herk\u00f6mmlichen Dateioperationen gibt es eine Anmerkung, die besagt, dass wenn jeder von zwei Threads diese Funktionen aufruft, jeder Aufruf entweder alle angegebenen Auswirkungen, die aus der Ausf\u00fchrung des anderen Aufrufs resultieren, oder gar keine Auswirkungen sehen muss. Das f\u00fchrt zu dem Schluss, dass alle Ein- und Ausgabe-Dateioperationen die Sperre der Ressource, mit der sie arbeiten, aufrechterhalten m\u00fcssen.<\/p>\n

Bedeutet das, dass die Operation write()<\/code> atomar ist? Aus technischer Sicht \u2014 ja. Leseoperationen sollten entweder alles oder nichts von dem zur\u00fcckgeben, was durch write()<\/code>geschrieben wurde. Aber die Operation write()<\/code>muss gem\u00e4\u00df dem Standard nicht unbedingt abgeschlossen werden, indem sie alles, was ihr angeboten wurde, schreibt. Es ist erlaubt, nur einen Teil der Daten zu schreiben. Zum Beispiel k\u00f6nnen wir zwei Threads haben, die jeweils 1024 Bytes an eine Datei anh\u00e4ngen, die durch denselben Dateideskriptor beschrieben wird. Aus der Sicht des Standards ist es akzeptabel, wenn jede der Schreiboperationen nur ein Byte an die Datei anh\u00e4ngen kann. Diese Operationen bleiben atomic, aber nachdem sie abgeschlossen sind, sind die Daten, die sie in die Datei geschrieben haben, vermischt. Hier<\/a><\/noindex> eine sehr interessante Diskussion zu diesem Thema auf Stack Overflow.<\/p>\n

Die Funktionen fsync() und fdatasync()<\/h2>\n

\nDer einfachste Weg, Daten auf die Festplatte zu schreiben, besteht darin, die Funktion fsync()<\/a><\/noindex>. Diese Funktion fordert das Betriebssystem auf, alle modifizierten Bl\u00f6cke aus dem Cache auf die Festplatte zu \u00fcbertragen. Dazu geh\u00f6ren auch alle Metadaten der Datei (Zugriffszeit, \u00c4nderungszeit der Datei usw.). Ich denke, dass der Bedarf an diesen Metadaten selten auftritt, also wenn Sie wissen, dass sie f\u00fcr Sie nicht wichtig sind, k\u00f6nnen Sie die Funktion fdatasync()<\/code>. In Hilfe<\/a><\/noindex> nach fdatasync()<\/code> sagt, dass im Laufe dieser Funktion eine solche Menge an Metadaten auf die Festplatte gespeichert wird, die 'notwendig ist, um die n\u00e4chsten Leseoperationen korrekt auszuf\u00fchren'. Und das ist genau das, was die meisten Anwendungen besch\u00e4ftigt.<\/p>\n

Ein Problem, das hier auftreten kann, besteht darin, dass diese Mechanismen nicht garantieren, dass die Datei nach einem m\u00f6glichen Absturz wieder gefunden werden kann. Insbesondere muss beim Erstellen einer neuen Datei ein Aufruf get\u00e4tigt werden fsync()<\/code> f\u00fcr das Verzeichnis, das ihn enth\u00e4lt. Andernfalls kann es nach einem Fehler so sein, dass diese Datei nicht existiert. Der Grund daf\u00fcr liegt darin, dass unter UNIX, aufgrund der Verwendung von Hardlinks, eine Datei in mehreren Verzeichnissen existieren kann. Daher bei einem Aufruf fsync()<\/code> gibt es keine M\u00f6glichkeit, herauszufinden, welche Daten eines bestimmten Verzeichnisses ebenfalls auf die Festplatte geschrieben werden m\u00fcssen (hier<\/a><\/noindex> dar\u00fcber kann man ausf\u00fchrlicher lesen). Es scheint, dass das Dateisystem ext4 in der Lage ist automatisch<\/a><\/noindex> einzusetzen fsync()<\/code> zu Verzeichnissen, die die entsprechenden Dateien enthalten, aber in F\u00e4llen mit anderen Dateisystemen k\u00f6nnte das anders sein.<\/p>\n

Dieser Mechanismus kann in verschiedenen Dateisystemen unterschiedlich implementiert werden. Ich habe verwendet blktrace<\/a><\/noindex> um herauszufinden, welche Festplattenoperationen in den Dateisystemen ext4 und XFS verwendet werden. Beide geben herk\u00f6mmliche Schreibbefehle sowohl f\u00fcr den Inhalt von Dateien als auch f\u00fcr das Journal des Dateisystems aus, schreiben den Cache zur\u00fcck und beenden die Ausf\u00fchrung, indem sie eine FUA-Schreibung (Force Unit Access, direkte Datenschreibung auf die Festplatte, um den Cache herum) ins Journal ausf\u00fchren. Wahrscheinlich machen sie dies, um den Abschluss der Operation zu best\u00e4tigen. Auf Festplatten, die FUA nicht unterst\u00fctzen, f\u00fchrt dies zu zwei Cache-R\u00fcckschreibungen. Meine Experimente zeigten, dass fdatasync()<\/code> ein wenig schneller fsync()<\/code>. Das Tool blktrace<\/code> darauf hinweist, dass fdatasync()<\/code> in der Regel weniger Daten auf die Festplatte schreibt (in ext4 fsync()<\/code> schreibt 20 KiB, und fdatasync()<\/code> \u2014 16 KiB). Au\u00dferdem habe ich festgestellt, dass XFS etwas schneller ist als ext4. Und dabei konnte ich blktrace<\/code> herausfinden, dass fdatasync()<\/code> weniger Daten auf die Festplatte zur\u00fcckschreibt (4 KiB in XFS).<\/p>\n

Uneindeutige Situationen, die bei der Verwendung von fsync() auftreten<\/h2>\n

\nIch kann mich an drei uneindeutige Situationen erinnern, die sich beziehen auf fsync()<\/code>, mit denen ich in der Praxis konfrontiert war.<\/p>\n

Der erste solche Fall trat 2008 auf. Damals \u201ehing\u201c die Benutzeroberfl\u00e4che von Firefox 3, wenn eine gro\u00dfe Anzahl von Dateien auf die Festplatte geschrieben wurde. Das Problem lag darin, dass bei der Implementierung der Benutzeroberfl\u00e4che eine SQLite-Datenbank verwendet wurde, um Informationen \u00fcber ihren Status zu speichern. Nach jeder \u00c4nderung, die in der Benutzeroberfl\u00e4che stattfand, wurde die Funktion fsync()<\/code>aufgerufen, was gute Garantien f\u00fcr die dauerhafte Speicherung der Daten bot. Im damals verwendeten Dateisystem ext3 war die Funktion fsync()<\/code> Sie hat alle \"schmutzigen\" Seiten im System auf die Festplatte zur\u00fcckgesetzt, nicht nur die, die mit der entsprechenden Datei zu tun hatten. Das bedeutete, dass ein Klick auf die Schaltfl\u00e4che in Firefox die Aufzeichnung von Megabytes an Daten auf die magnetische Festplatte initiieren konnte, was viele Sekunden in Anspruch nehmen konnte. Die L\u00f6sung des Problems bestand, wie ich verstand, darin, dieses<\/a><\/noindex> die Arbeiten mit der Datenbank in asynchrone Hintergrundaufgaben zu verlagern. Das bedeutet, dass Firefox fr\u00fcher strengere Anforderungen an die Stabilit\u00e4t der Datenspeicherung hatte, als es wirklich n\u00f6tig war, und die Besonderheiten des ext3-Dateisystems das Problem nur versch\u00e4rften.<\/p>\n

Das zweite Missverh\u00e4ltnis trat im Jahr 2009 auf. Nach einem Systemausfall begegneten Benutzer des neuen ext4-Dateisystems dem Problem, dass viele neu erstellte Dateien eine null L\u00e4nge hatten, w\u00e4hrend dies beim \u00e4lteren ext3-Dateisystem nicht der Fall war. Im vorherigen Absatz sprach ich dar\u00fcber, dass ext3 zu viele Daten auf die Festplatte zur\u00fccksetzte, was die Leistung stark verlangsamte fsync()<\/code>. Um die Situation zu verbessern, werden beim ext4 nur die \"schmutzigen\" Seiten auf die Festplatte zur\u00fcckgesetzt, die mit einer bestimmten Datei zu tun haben. Die Daten anderer Dateien bleiben viel l\u00e4nger im Speicher als bei der Verwendung von ext3. Dies wurde zur Verbesserung der Leistung gemacht (standardm\u00e4\u00dfig verweilen die Daten in diesem Zustand 30 Sekunden, dies kann mit Hilfe von dirty_expire_centisecs<\/a><\/noindex>; hier<\/a><\/noindex> weiteren Materialien dazu gefunden werden). Das bedeutet, dass ein gro\u00dfer Datenvolumen nach einem Ausfall unwiderruflich verloren gehen kann. Die L\u00f6sung dieses Problems liegt in der Verwendung von fsync()<\/code> Anwendungen, die eine stabile Datenspeicherung gew\u00e4hrleisten und diese so gut wie m\u00f6glich vor den Folgen von Ausf\u00e4llen sch\u00fctzen m\u00fcssen. Die Funktion fsync()<\/code> arbeitet bei Verwendung von ext4 wesentlich effektiver als bei ext3. Der Nachteil eines solchen Ansatzes besteht darin, dass seine Anwendung, wie zuvor, die Ausf\u00fchrung bestimmter Vorg\u00e4nge, wie die Installation von Programmen, verlangsamt. Einzelheiten dazu finden Sie hier<\/a><\/noindex> und hier<\/a><\/noindex>.<\/p>\n

Das dritte Problem, das fsync()<\/code>, trat im Jahr 2018 auf. Im Rahmen des PostgreSQL-Projekts wurde festgestellt, dass, wenn die Funktion fsync()<\/code> auf einen Fehler st\u00f6\u00dft, sie die \"schmutzigen\" Seiten als \"sauber\" markiert. Infolgedessen f\u00fchrten die folgenden Aufrufe fsync()<\/code> Mit solchen Seiten wird nichts gemacht. Daher bleiben modifizierte Seiten im Speicher und werden niemals auf die Festplatte geschrieben. Dies ist eine echte Katastrophe, da die Anwendung denken wird, dass bestimmte Daten auf die Festplatte geschrieben wurden, was jedoch nicht der Fall sein wird. Solche Fehler fsync()<\/code> kommen selten vor, und die Anwendung kann in solchen Situationen kaum etwas unternehmen, um das Problem zu beheben. Heutzutage, wenn so etwas passiert, beendet PostgreSQL und andere Anwendungen die Arbeit unerwartet. Hier<\/a><\/noindex>, im Material \"K\u00f6nnen Anwendungen von fsync-Fehlern wiederherstellen?\", wird dieses Problem im Detail untersucht. Derzeit ist die beste L\u00f6sung f\u00fcr dieses Problem die Verwendung von Direct I\/O mit dem Flag O_SYNC<\/code> oder mit dem Flag O_DSYNC<\/code>. Bei diesem Ansatz meldet das System Fehler, die bei der Durchf\u00fchrung konkreter Schreiboperationen auftreten k\u00f6nnen, jedoch erfordert dieser Ansatz, dass die Anwendung die Puffer selbst verwaltet. Einzelheiten dazu finden Sie hier<\/a><\/noindex> und hier<\/a><\/noindex>.<\/p>\n

Die \u00d6ffnung von Dateien mit den Flags O_SYNC und O_DSYNC<\/h2>\n

\nKehren wir zur\u00fcck zur Diskussion \u00fcber die Mechanismen von Linux, die eine zuverl\u00e4ssige Datenspeicherung gew\u00e4hrleisten. Insbesondere geht es um die Verwendung des Flags O_SYNC<\/code> oder des Flags O_DSYNC<\/code> beim \u00d6ffnen von Dateien mit dem Systemaufruf open()<\/a><\/noindex>. Bei diesem Ansatz wird jede Schreiboperation so ausgef\u00fchrt, als ob nach jedem Befehl write()<\/code> dem System entsprechende Befehle erteilt werden, fsync()<\/code> und fdatasync()<\/code>. In den Spezifikationen von POSIX.<\/a><\/noindex> Dies wird als \"Synchronisierte I\/O-Dateiintegrit\u00e4tsvollst\u00e4ndigung\" und \"Datenintegrit\u00e4tsvollst\u00e4ndigung\" bezeichnet. Der Hauptvorteil dieses Ansatzes besteht darin, dass zur Gew\u00e4hrleistung der Datensicherheit nur ein Systemaufruf notwendig ist, nicht zwei (zum Beispiel \u2013 write()<\/code> und fdatasync()<\/code>). Der Hauptnachteil dieses Ansatzes ist, dass alle Schreiboperationen, die den entsprechenden Dateideskriptor verwenden, synchronisiert werden, was die M\u00f6glichkeiten zur Strukturierung des Anwendungscodes einschr\u00e4nken kann.<\/p>\n

Die Verwendung von Direct I\/O mit dem Flag O_DIRECT<\/h2>\n

\nSystemaufruf open()<\/code> unterst\u00fctzt das Flag O_DIRECT<\/code>, das dazu dient, Eingabe- und Ausgabeoperationen direkt mit der Festplatte durchzuf\u00fchren, indem der Cache des Betriebssystems umgangen wird. Dies bedeutet in vielen F\u00e4llen, dass die von der Software ausgegebenen Schreibbefehle direkt in die Befehle \u00fcbersetzt werden, die mit der Festplatte arbeiten. Im Allgemeinen ist dieser Mechanismus jedoch kein Ersatz f\u00fcr die Funktionen fsync()<\/code> oder fdatasync()<\/code>. Das Problem ist, dass die Festplatte selbst verschieben oder cachen<\/a><\/noindex> entsprechende Befehle zur Datenspeicherung. Und noch schlimmer, in einigen speziellen F\u00e4llen werden Ein- und Ausgabeoperationen durchgef\u00fchrt, w\u00e4hrend das Flag verwendet wird O_DIRECT<\/code>, ubertragen<\/a><\/noindex> in traditionelle gepufferte Operationen. Das Problem l\u00e4sst sich am einfachsten l\u00f6sen, indem man beim \u00d6ffnen von Dateien auch das Flag verwendet O_DSYNC<\/code>, was bedeutet, dass auf jede Schreiboperation ein Aufruf folgt fdatasync()<\/code>.<\/p>\n

Es stellte sich heraus, dass im XFS-Dateisystem k\u00fcrzlich ein \"schneller Pfad\" hinzugef\u00fcgt wurde f\u00fcr O_DIRECT|O_DSYNC<\/code>-Datenspeicherung. Wenn ein Block unter Verwendung von O_DIRECT|O_DSYNC<\/code>\u00fcberschrieben wird, wird XFS anstelle des Cache-Flushs den Befehl FUA-Schreibung ausf\u00fchren, sofern das Ger\u00e4t dies unterst\u00fctzt. Ich habe das selbst getestet mit dem Dienstprogramm blktrace<\/code> in Linux 5.4\/Ubuntu 20.04. Dieser Ansatz sollte effizienter sein, da dabei die minimale Datenmenge auf die Festplatte geschrieben wird und zudem nur eine Operation angewendet wird und nicht zwei (Schreiben und Cache-Flush). Ich fand einen Hinweis auf Patch<\/a><\/noindex> den Kernel aus dem Jahr 2018, in dem dieser Mechanismus implementiert ist. Dort gibt es eine Diskussion \u00fcber die Anwendung dieser Optimierung in anderen Dateisystemen, aber soweit ich wei\u00df, ist XFS bisher das einzige Dateisystem, das dies unterst\u00fctzt.<\/p>\n

Die Funktion sync_file_range()<\/h2>\n

\nIn Linux gibt es einen Systemaufruf sync_file_range()<\/a><\/noindex>, der es erm\u00f6glicht, nur einen Teil einer Datei auf die Festplatte zu schreiben, anstatt die gesamte Datei. Dieser Aufruf initiiert einen asynchronen Daten-Flush und wartet nicht auf dessen Abschluss. Doch in der Dokumentation zu sync_file_range()<\/code> wird gesagt, dass dieser Befehl \"sehr gef\u00e4hrlich\" ist. Die Nutzung wird nicht empfohlen. Die Besonderheiten und Gefahren sync_file_range()<\/code> sind sehr gut beschrieben in das<\/a><\/noindex> dem Material. Insbesondere scheint es, dass dieser Aufruf RocksDB verwendet, um zu steuern, wann der Kernel \"verunreinigte\" Daten auf die Festplatte schreibt. Dabei wird auch fdatasync()<\/code>. In Eine neue SQLite-Version mit dem Patch ist bisher<\/a><\/noindex> RocksDB gibt es interessante Kommentare zu diesem Thema. Beispielsweise scheint der Aufruf sync_file_range()<\/code> bei der Verwendung von ZFS nicht zu einem Flush der Daten auf die Festplatte zu f\u00fchren. Erfahrungsgem\u00e4\u00df vermute ich, dass Code, der selten verwendet wird, m\u00f6glicherweise Fehler enth\u00e4lt. Daher w\u00fcrde ich empfehlen, diesen Systemaufruf nur im \u00e4u\u00dfersten Notfall zu verwenden.<\/p>\n

Systemaufrufe, die helfen, die Datenintegrit\u00e4t zu gew\u00e4hrleisten<\/h2>\n

\nIch komme zu dem Schluss, dass zur Durchf\u00fchrung von Ein-\/Ausgabeoperationen, die eine nachhaltige Datenspeicherung gew\u00e4hrleisten, drei Ans\u00e4tze verwendet werden k\u00f6nnen. Alle erfordern den Aufruf der Funktion fsync()<\/code> f\u00fcr das Verzeichnis, in dem die Datei erstellt wurde. Hier sind die Ans\u00e4tze:<\/p>\n

    \n
  1. Aufruf der Funktion fdatasync()<\/code> oder fsync()<\/code> nach der Funktion write()<\/code> (es ist besser, zu verwenden fdatasync()<\/code>).<\/li>\n
  2. Arbeiten mit einem Dateideskriptor, der mit dem Flag ge\u00f6ffnet wurde O_DSYNC<\/code> oder O_SYNC<\/code> (besser \u2013 mit dem Flag O_DSYNC<\/code>).<\/li>\n
  3. Verwendung des Befehls pwritev2()<\/code> mit dem Flag RWF_DSYNC<\/code> oder RWF_SYNC<\/code> (vorzugsweise \u2013 mit dem Flag RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Hinweise zur Leistung<\/h2>\n

    \nIch habe keine gr\u00fcndlichen Leistungsmessungen der verschiedenen von mir untersuchten Mechanismen durchgef\u00fchrt. Die von mir festgestellten Geschwindigkeitsunterschiede sind ziemlich gering. Das bedeutet, dass ich mich irren kann und dass das gleiche unter anderen Bedingungen andere Ergebnisse zeigen kann. Zun\u00e4chst werde ich dar\u00fcber berichten, was sich st\u00e4rker auf die Leistung auswirkt, und dann, was sich weniger auf die Leistung auswirkt.<\/p>\n

      \n
    1. Das \u00dcberschreiben von Dateidaten ist schneller als das Anh\u00e4ngen von Daten an die Datei (der Leistungsgewinn kann 2-100% betragen). Das Anh\u00e4ngen von Daten an die Datei erfordert zus\u00e4tzliche \u00c4nderungen an den Metadaten der Datei, selbst nach dem Systemaufruf fallocate()<\/code>, aber das Ausma\u00df dieses Effekts kann variieren. Ich empfehle, um die beste Leistung zu gew\u00e4hrleisten, den Aufruf fallocate()<\/code> zur Voraballokation des ben\u00f6tigten Raums. Danach muss dieser Raum explizit mit Nullen gef\u00fcllt und der Aufruf fsync()<\/code>get\u00e4tigt werden. Dadurch werden die entsprechenden Bl\u00f6cke im Dateisystem als \"allokiert\" und nicht als \"nicht allokiert\" markiert. Dies f\u00fchrt zu einer geringf\u00fcgigen (circa 2%) Verbesserung der Leistung. Zudem kann bei einigen Festplatten die erste Zugriffsoperation auf einen Block langsamer sein als bei anderen. Das bedeutet, dass das F\u00fcllen des Raums mit Nullen zu einer erheblichen (circa 100%) Verbesserung der Leistung f\u00fchren kann. Dies kann insbesondere bei den Festplatten AWS EBS<\/a><\/noindex> (das sind inoffizielle Daten, die ich nicht best\u00e4tigen konnte). Das Gleiche gilt f\u00fcr die Speicher GCP Persistent Disk<\/a><\/noindex> (und das ist bereits offizielle Information, die durch Tests best\u00e4tigt wurde). Andere Spezialisten haben \u00e4hnliche Beobachtungen<\/a><\/noindex>, die verschiedene Festplatten betreffen.<\/li>\n
    2. Je weniger Systemaufrufe \u2013 desto h\u00f6her die Leistung (der Gewinn kann etwa 5% betragen). Es scheint, dass der Aufruf open()<\/code> mit dem Flag O_DSYNC<\/code> oder der Aufruf pwritev2()<\/code> mit dem Flag RWF_SYNC<\/code> schneller ist als der Aufruf fdatasync()<\/code>Ich vermute, dass der Grund darin liegt, dass bei solch einem Ansatz die Anzahl der Systemaufrufe zur L\u00f6sung derselben Aufgabe reduziert werden kann (ein Aufruf statt zwei). Der Leistungsunterschied ist jedoch sehr gering, sodass Sie dies vernachl\u00e4ssigen und in der Anwendung verwenden k\u00f6nnen, was die Logik nicht zus\u00e4tzlich verkompliziert.<\/li>\n<\/ol>\n

      \nWenn Sie sich f\u00fcr das Thema robustes Datenmanagement interessieren \u2013 hier sind einige n\u00fctzliche Materialien:<\/p>\n