{"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":"Zuverl\u00e4ssige Datenspeicherung und Dateischnittstellen in Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ich habe die Zuverl\u00e4ssigkeit der Datenspeicherung in Cloud-Systemen untersucht und wollte mich selbst pr\u00fcfen, um sicherzustellen, dass ich die Grundlagen verstehe. Ich begann mit dem Lesen der NVMe-Spezifikation<\/a><\/noindex> , um herauszufinden, welche Garantien in Bezug auf die zuverl\u00e4ssige Datenspeicherung (also die Garantien, dass Daten nach einem Systemausfall verf\u00fcgbar sind) uns NVMe-Laufwerke bieten. Meine wichtigsten Erkenntnisse waren: Man muss Daten als besch\u00e4digt betrachten, sobald der Befehl zur Datenaufnahme gegeben wird, und bis der Schreibvorgang auf dem Speichermedium abgeschlossen ist. In den meisten Datensatzprogrammen werden allerdings system calls ganz ungeniert verwendet.<\/p>\n

In diesem Material untersuche ich die Mechanismen der zuverl\u00e4ssigen Datenspeicherung, die die Dateisystem-APIs von Linux bereitstellen. Es scheint, als sollte das einfach sein: Das Programm ruft den Befehl write(),<\/code>, und nachdem dieser Befehl ausgef\u00fchrt wurde, sollten die Daten sicher auf der Festplatte gespeichert sein. Aber write(),<\/code> kopiert nur die Anwendungsdaten in den Kernel-Cache, der im Arbeitsspeicher liegt. Um das System dazu zu zwingen, die Daten auf die Festplatte zu schreiben, m\u00fcssen einige zus\u00e4tzliche Mechanismen verwendet werden.<\/p>\n

\"Zuverl\u00e4ssige<\/a><\/noindex><\/p>\n

Insgesamt handelt es sich bei diesem Material um eine Sammlung von Notizen zu dem, was ich \u00fcber das f\u00fcr mich interessante Thema gelernt habe. Um das Wichtigste kurz zusammenzufassen: F\u00fcr eine nachhaltige Datenspeicherung sollte man den Befehl verwenden fdatasync()<\/code> oder Dateien mit dem Flag O_DSYNC<\/code>. Wenn Sie mehr \u00fcber die Details erfahren m\u00f6chten, die mit den Daten auf dem Weg vom Programmcode zur Festplatte verbunden sind, werfen Sie einen Blick auf dieses<\/a><\/noindex> den Artikel.
\n<\/a><\/noindex><\/p>\n

Eigenschaften der Funktion write()<\/h2>\n

\nSystemaufruf write(),<\/code> wird im Standard IEEE POSIX<\/a><\/noindex> als Versuch definiert, Daten in einen Dateideskriptor zu schreiben. Nach erfolgreichem Abschluss write(),<\/code> sollten Leseoperationen genau die Bytes zur\u00fcckgeben, die zuvor geschrieben wurden, selbst wenn auf die Daten von anderen Prozessen oder Threads zugegriffen wird (hier ist<\/a><\/noindex> entsprechender Abschnitt des POSIX-Standards). Hier<\/a><\/noindex>, im Abschnitt, der sich mit der Interaktion von Threads und herk\u00f6mmlichen Dateioperationen befasst, gibt es einen Hinweis, der besagt, dass, wenn jeder der beiden Threads diese Funktionen aufruft, jeder Aufruf entweder alle spezifizierten Nebenwirkungen des anderen Aufrufs sehen sollte oder \u00fcberhaupt keine Nebenwirkungen. Dies f\u00fchrt zu der Schlussfolgerung, dass alle Datei-Eingabe\/Ausgabe-Operationen die Ressource, mit der sie arbeiten, sperren sollten.<\/p>\n

Bedeutet das, dass die Operation write(),<\/code> atomar ist? Technisch gesehen \u2013 ja. Lesevorg\u00e4nge sollten entweder alles oder nichts von dem zur\u00fcckgeben, was durch write(),<\/code>geschrieben wurde. Aber die Operation write(),<\/code>, gem\u00e4\u00df dem Standard, muss nicht unbedingt alles, was ihr angeboten wurde, aufgezeichnet werden. Es ist ihr erlaubt, nur einen Teil der Daten zu speichern. Zum Beispiel k\u00f6nnen wir zwei Streams haben, die jeweils 1024 Byte zu einer Datei hinzuf\u00fcgen, die durch denselben Descriptor beschrieben wird. Aus Sicht des Standards w\u00e4re das akzeptable Ergebnis, wenn jede der Schreiboperationen nur ein Byte an die Datei anh\u00e4ngen kann. Diese Operationen bleiben atomar, aber nachdem sie abgeschlossen sind, werden die von ihnen in die Datei geschriebenen Daten vermischt sein. 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>aufzurufen. 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 glaube, dass der Bedarf an diesen Metadaten selten auftritt, daher k\u00f6nnen Sie die Funktion fdatasync()<\/code>In nachschlagen<\/a><\/noindex> zum fdatasync()<\/code> Es wird gesagt, dass bei der Ausf\u00fchrung dieser Funktion eine Menge an Metadaten auf die Festplatte gespeichert wird, die \"notwendig ist, um die folgenden Datenlesevorg\u00e4nge korrekt durchzuf\u00fchren\". Und das ist genau das, was die meisten Anwendungen betrifft.<\/p>\n

Ein Problem, das hier auftreten kann, besteht darin, dass diese Mechanismen nicht garantieren, dass die Datei nach einem m\u00f6glichen Ausfall gefunden werden kann. Insbesondere muss beim Erstellen einer neuen Datei fsync()<\/code> auf das Verzeichnis, das sie enth\u00e4lt, aufgerufen werden. Andernfalls kann es nach einem Ausfall passieren, dass diese Datei nicht existiert. Der Grund daf\u00fcr ist, dass in UNIX, aufgrund von harten Verlinkungen, eine Datei in mehreren Verzeichnissen existieren kann. Daher gibt es beim Aufruf von fsync()<\/code> keinen Weg zu erfahren, dass die Daten eines bestimmten Verzeichnisses ebenfalls auf die Festplatte geschrieben werden m\u00fcssen (hier<\/a><\/noindex> dar\u00fcber kann man n\u00e4her lesen). Anscheinend ist das Dateisystem ext4 f\u00e4hig, automatisch<\/a><\/noindex> anzuwenden fsync()<\/code> zu Verzeichnissen zu verlinken, die die entsprechenden Dateien enthalten, aber bei anderen Dateisystemen k\u00f6nnte dies anders sein.<\/p>\n

Dieser Mechanismus kann in verschiedenen Dateisystemen unterschiedlich implementiert sein. Ich habe verwendet blktrace<\/a><\/noindex> um herauszufinden, welche Diskoperationen in den Dateisystemen ext4 und XFS verwendet werden. Beide f\u00fchren normale Schreibbefehle auf die Festplatte sowohl f\u00fcr den Dateiinhalte als auch f\u00fcr das Dateisystemprotokoll aus, leeren den Cache und beenden den Vorgang, indem sie eine FUA-Aufzeichnung (Force Unit Access, das direkte Schreiben von Daten auf die Festplatte, um den Cache zu umgehen) im Protokoll durchf\u00fchren. Wahrscheinlich machen sie das, um den Abschluss der Operation zu best\u00e4tigen. Bei Festplatten, die FUA nicht unterst\u00fctzen, f\u00fchrt dies zu zwei Cache-Leerungen. Meine Experimente haben gezeigt, dass fdatasync()<\/code> etwas schneller fsync()<\/code>. Das Tool blktrace<\/code> darauf hinweist, dass fdatasync()<\/code> normalerweise weniger Daten auf die Festplatte schreibt (in ext4 fsync()<\/code> werden 20 KiB geschrieben, w\u00e4hrend fdatasync()<\/code> 16 KiB). Au\u00dferdem habe ich festgestellt, dass XFS etwas schneller ist als ext4. Dabei konnte ich blktrace<\/code> herausfinden, dass fdatasync()<\/code> weniger Daten auf die Festplatte leert (4 KiB in XFS).<\/p>\n

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

\nIch kann mich an drei ambivalente Situationen erinnern, die ich in der Praxis erlebt habe. fsync()<\/code>, mit denen ich konfrontiert wurde.<\/p>\n

Der erste solche Fall trat 2008 auf. Damals kam es bei der Benutzeroberfl\u00e4che von Firefox 3 zu Verz\u00f6gerungen, wenn eine gro\u00dfe Zahl von Dateien auf die Festplatte geschrieben wurde. Das Problem lag darin, dass bei der Implementierung der Benutzeroberfl\u00e4che zur Speicherung ihrer Zustandsinformationen eine SQLite-Datenbank verwendet wurde. Nach jeder \u00c4nderung in der Benutzeroberfl\u00e4che wurde eine Funktion aufgerufen fsync()<\/code>, die gute Garantien f\u00fcr die zuverl\u00e4ssige Speicherung der Daten gab. Im damals verwendeten Dateisystem ext3 sorgte die Funktion fsync()<\/code> daf\u00fcr, dass alle \"schmutzigen\" Seiten im System auf die Festplatte geschrieben wurden, und nicht nur die Seiten, die zu der betreffenden Datei geh\u00f6rten. Das bedeutete, dass ein Klick auf eine Schaltfl\u00e4che in Firefox das Schreiben von Megabyte an Daten auf die magnetische Festplatte ausl\u00f6sen konnte, was viele Sekunden in Anspruch nehmen konnte. Die L\u00f6sung des Problems, so wie ich das aus dieses Ergebnis herauskommt<\/a><\/noindex> dem Material verstanden habe, bestand darin, die Arbeit mit der Datenbank in asynchrone Hintergrundaufgaben zu verlagern. Das bedeutet, dass fr\u00fcher in Firefox strengere Anforderungen an die zuverl\u00e4ssige Speicherung der Daten umgesetzt wurden, als tats\u00e4chlich n\u00f6tig gewesen w\u00e4ren, und die Eigenschaften des Dateisystems ext3 dieses Problem nur versch\u00e4rften.<\/p>\n

Das zweite Problem trat im Jahr 2009 auf. Nach einem Systemausfall hatten Benutzer des neuen Dateisystems ext4 das Problem, dass viele neu erstellte Dateien eine Nulll\u00e4nge hatten, w\u00e4hrend bei dem \u00e4lteren Dateisystem ext3 dies nicht der Fall war. Im vorherigen Absatz erw\u00e4hnte ich, dass ext3 zu viele Daten auf die Festplatte schrieb, was die Leistung erheblich verlangsamte. fsync()<\/code>Um die Situation zu verbessern, schreibt ext4 nur die \u201eschmutzigen\u201c Seiten auf die Festplatte, die sich auf eine bestimmte Datei beziehen. Die Daten anderer Dateien bleiben viel l\u00e4nger im Speicher als dies bei ext3 der Fall war. Dies wurde zur Leistungssteigerung eingef\u00fchrt (standardm\u00e4\u00dfig bleiben die Daten 30 Sekunden in diesem Zustand; dies kann mit Hilfe von dirty_expire_centisecs<\/a><\/noindex>; hier<\/a><\/noindex> zus\u00e4tzlichen Materialien dar\u00fcber gefunden werden). Dies bedeutet, dass ein gro\u00dfer Datenumfang nach einem Ausfall unwiderruflich verloren gehen kann. Die L\u00f6sung dieses Problems liegt im Einsatz von fsync()<\/code> Anwendungen, die eine dauerhafte Datenspeicherung sicherstellen und sie bestm\u00f6glich vor den Folgen von Ausf\u00e4llen sch\u00fctzen m\u00fcssen. Die Funktion fsync()<\/code> arbeitet bei der Anwendung von ext4 deutlich effizienter als bei ext3. Der Nachteil dieses Ansatzes besteht darin, dass seine Anwendung, wie zuvor, die Ausf\u00fchrung bestimmter Operationen, wie die Installation von Programmen, verlangsamt. Weitere Einzelheiten dazu finden Sie hier<\/a><\/noindex> \u0438 hier<\/a><\/noindex>.<\/p>\n

Das dritte Problem, das sich bezieht auf fsync()<\/code>, trat im Jahr 2018 auf. Damals wurde im Rahmen des PostgreSQL-Projekts herausgefunden, dass wenn die Funktion fsync()<\/code> auf einen Fehler st\u00f6\u00dft, sie \u00bbschmutzige\u00ab Seiten als \u00bbsauber\u00ab kennzeichnet. Infolgedessen f\u00fchren die folgenden Aufrufe fsync()<\/code> nichts mit solchen Seiten durch. Aufgrund dessen verbleiben modifizierte Seiten im Speicher und werden nie auf die Festplatte geschrieben. Dies ist eine echte Katastrophe, da die Anwendung glauben wird, dass bestimmte Daten auf die Festplatte geschrieben wurden, in Wirklichkeit aber nicht. Solche Fehler fsync()<\/code> sind selten, die Anwendung kann in solchen Situationen fast nichts tun, um das Problem zu bek\u00e4mpfen. Heutzutage, wenn dies passiert, beenden PostgreSQL und andere Anwendungen unerwartet. Hier<\/a><\/noindex>, im Artikel \u201eCan Applications Recover from fsync Failures?\u201c, wird dieses Problem ausf\u00fchrlich behandelt. Derzeit besteht die beste L\u00f6sung f\u00fcr dieses Problem in der Verwendung von Direct I\/O mit dem Flag O_SYNC<\/code> oder mit dem Flag O_DSYNC<\/code>. Bei diesem Ansatz wird das System \u00fcber Fehler informieren, die bei der Durchf\u00fchrung bestimmter Datenaufzeichnungsoperationen auftreten k\u00f6nnen, erfordert jedoch, dass die Anwendung die Puffer selbst verwaltet. Weitere Informationen dazu finden Sie hier<\/a><\/noindex> \u0438 hier<\/a><\/noindex>.<\/p>\n

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

\nKehren wir zur Diskussion \u00fcber die Mechanismen von Linux zur\u00fcck, die eine zuverl\u00e4ssige Datenspeicherung gew\u00e4hrleisten. Insbesondere beziehen wir uns auf die Verwendung des Flags O_SYNC<\/code> oder des Flags O_DSYNC<\/code> beim \u00d6ffnen von Dateien mit einem Systemaufruf open(),<\/a><\/noindex>. Bei diesem Ansatz wird jede Datenaufzeichnungsoperation so ausgef\u00fchrt, als ob nach jedem Befehl write(),<\/code> dem System entsprechend Befehle erteilt werden fsync()<\/code> \u0438 fdatasync()<\/code>In der POSIX-Spezifikation<\/a><\/noindex> wird dies als \u201eSynchronized I\/O File Integrity Completion\u201c und \u201eData Integrity Completion\u201c bezeichnet. Der Hauptvorteil dieses Ansatzes besteht darin, dass f\u00fcr die Gew\u00e4hrleistung der Datenintegrit\u00e4t lediglich ein Systemaufruf erforderlich ist, nicht zwei (zum Beispiel \u2014 write(),<\/code> \u0438 fdatasync()<\/code>). Der Hauptnachteil dieses Ansatzes besteht darin, dass alle Schreiboperationen, die den entsprechenden Dateideskriptor verwenden, synchronisiert werden, was die M\u00f6glichkeiten zur Strukturierung des Anwendungscodes einschr\u00e4nken kann.<\/p>\n

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

\nSystemaufruf open(),<\/code> unterst\u00fctzt das Flag O_DIRECT<\/code>, das dazu dient, Eingabe-\/Ausgabeoperationen direkt mit der Festplatte durchzuf\u00fchren, indem der Cache des Betriebssystems umgangen wird. Das bedeutet in vielen F\u00e4llen, dass die von der Software ausgegebenen Schreibbefehle direkt in Befehle f\u00fcr die Arbeit mit der Festplatte umgesetzt werden. Generally, this mechanism is not a replacement for the functions fsync()<\/code> \u0438\u043b\u0438 fdatasync()<\/code>. Das Problem ist, dass die Festplatte selbst Befehle zum Schreiben von Daten<\/a><\/noindex> verz\u00f6gern oder cachen kann. Und was noch schlimmer ist, in einigen speziellen F\u00e4llen werden die Eingabe-\/Ausgabeoperationen, die unter Verwendung des Flags O_DIRECT<\/code>, in traditionelle gepufferte Operationen umgewandelt.<\/a><\/noindex> Das Problem l\u00e4sst sich am einfachsten l\u00f6sen, indem man beim \u00d6ffnen von Dateien auch das Flag O_DSYNC<\/code>verwendet, was bedeutet, dass jeder Schreiboperation ein Aufruf folgt fdatasync()<\/code>.<\/p>\n

Es stellte sich heraus, dass in das XFS-Dateisystem k\u00fcrzlich ein 'schneller Pfad' f\u00fcr O_DIRECT|O_DSYNC<\/code>zum Schreiben von Daten hinzugef\u00fcgt wurde. Wenn ein Block mit Verwendung von O_DIRECT|O_DSYNC<\/code>, dann wird XFS anstelle des Cache-Flushs den FUA-Schreibbefehl ausf\u00fchren, sofern das Ger\u00e4t dies unterst\u00fctzt. Das habe ich mit dem Tool \u00fcberpr\u00fcft blktrace<\/code> unter Linux 5.4\/Ubuntu 20.04. Dieser Ansatz sollte effizienter sein, da bei seiner Verwendung eine minimale Menge an Daten auf die Festplatte geschrieben wird und nur eine Operation verwendet wird, nicht zwei (Schreiben und Cache-Flush). Ich fand einen Link zu Patch<\/a><\/noindex> einem Kernel aus dem Jahr 2018, in dem dieser Mechanismus implementiert ist. Dort wird diskutiert, ob diese Optimierung auch in anderen Dateisystemen angewendet werden kann, aber soweit ich wei\u00df, ist XFS derzeit 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 eine asynchrone Daten\u00fcbertragung und wartet nicht auf deren Abschluss. Aber in der Dokumentation zu sync_file_range()<\/code> wird gesagt, dass dieser Befehl \"sehr gef\u00e4hrlich\" ist. Es wird nicht empfohlen, ihn zu verwenden. Die Besonderheiten und Gefahren sync_file_range()<\/code> sind sehr gut beschrieben in diesem<\/a><\/noindex> In dem Material. Insbesondere scheint dieser Aufruf RocksDB zu verwenden, um zu steuern, wann der Kernel \"schmutzige\" Daten auf die Festplatte schreibt. Dabei wird jedoch auch f\u00fcr die dauerhafte Speicherung von Daten fdatasync()<\/code>In Code<\/a><\/noindex> Bei RocksDB gibt es interessante Kommentare zu diesem Thema. Zum Beispiel scheint es, dass der Aufruf sync_file_range()<\/code> bei der Verwendung von ZFS nicht zu einem Schreiben von Daten auf die Festplatte f\u00fchrt. Die Erfahrung zeigt mir, dass seltener genutzter Code m\u00f6glicherweise Fehler enth\u00e4lt. Daher w\u00fcrde ich raten, diesen Systemaufruf nur im \u00e4u\u00dfersten Notfall zu verwenden.<\/p>\n

Systemaufrufe, die die dauerhafte Speicherung von Daten unterst\u00fctzen<\/h2>\n

\nIch bin zu dem Schluss gekommen, dass f\u00fcr die Durchf\u00fchrung von Ein-\/Ausgabe-Operationen, die die dauerhafte Speicherung von Daten 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 diese Ans\u00e4tze:<\/p>\n

    \n
  1. Der Aufruf der Funktion fdatasync()<\/code> \u0438\u043b\u0438 fsync()<\/code> nach der Funktion write(),<\/code> (es ist besser, fdatasync()<\/code>).<\/li>\n
  2. Mit einem Dateideskriptor zu arbeiten, der mit der Flagge O_DSYNC<\/code> \u0438\u043b\u0438 O_SYNC<\/code> (besser \u2014 mit der Flagge O_DSYNC<\/code>).<\/li>\n
  3. Verwendung des Befehls pwritev2()<\/code> das Flag RWF_DSYNC<\/code> \u0438\u043b\u0438 RWF_SYNC<\/code> (bevorzugt \u2014 mit der Flagge RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Leistungsnotizen<\/h2>\n

    \nIch habe die Leistung der verschiedenen von mir untersuchten Mechanismen nicht sorgf\u00e4ltig gemessen. Die Unterschiede in der Geschwindigkeit, die mir aufgefallen sind, sind recht gering. Das bedeutet, dass ich mich irren k\u00f6nnte und dass unter anderen Bedingungen dasselbe zu anderen Ergebnissen f\u00fchren kann. Zuerst werde ich dar\u00fcber sprechen, was einen st\u00e4rkeren Einfluss auf die Leistung hat, und danach, was weniger Einfluss auf die Leistung hat.<\/p>\n

      \n
    1. Das \u00dcberschreiben von Daten in einer Datei ist schneller als das Anh\u00e4ngen von Daten an eine Datei (der Leistungsgewinn kann 2-100% betragen). Das Anh\u00e4ngen von Daten an eine 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, einen Aufruf zu t\u00e4tigen fallocate()<\/code> zum vorherigen Reservieren des ben\u00f6tigten Speicherplatzes. Danach sollte dieser Speicherplatz ausdr\u00fccklich mit Nullen gef\u00fcllt und aufgerufen werden. fsync()<\/code>. Dadurch werden die entsprechenden Bl\u00f6cke im Dateisystem als \u201eausgew\u00e4hlt\u201c und nicht als \u201enicht ausgew\u00e4hlt\u201c markiert. Dies erm\u00f6glicht eine geringe (etwa 2%) Leistungsverbesserung. Au\u00dferdem kann bei einigen Laufwerken die erste Zugriffsoperation auf einen Block langsamer sein als bei anderen. Das bedeutet, dass das Auff\u00fcllen des Speichers mit Nullen eine signifikante (von etwa 100%) Leistungsverbesserung zur Folge haben kann. Insbesondere kann dies bei Laufwerken auftreten. AWS EBS<\/a><\/noindex> (dies sind inoffizielle Daten, die ich nicht best\u00e4tigen konnte). Dasselbe gilt f\u00fcr die Speicherl\u00f6sungen. GCP Persistent Disk<\/a><\/noindex> (dies ist bereits offizielle Information, die durch Tests best\u00e4tigt wurde). Andere Experten haben \u00e4hnliche Beobachtungen<\/a><\/noindex>, die sich auf verschiedene Laufwerke beziehen.<\/li>\n
    2. Je weniger Systemaufrufe \u2013 desto h\u00f6her die Leistung (die Verbesserung kann etwa 5% betragen). Es scheint, dass der Aufruf open(),<\/code> das Flag O_DSYNC<\/code> oder der Aufruf pwritev2()<\/code> das Flag RWF_SYNC<\/code> schneller ist als der Aufruf fdatasync()<\/code>. Ich vermute, dass es daran liegt, dass bei einem solchen Ansatz die Rolle spielt, dass f\u00fcr die L\u00f6sung derselben Aufgabe weniger Systemaufrufe erforderlich sind (ein Aufruf anstelle von zwei). Aber der Leistungsunterschied ist sehr gering, sodass Sie ihn getrost ignorieren und in der Anwendung verwenden k\u00f6nnen, was die Logik nicht komplizierter macht.<\/li>\n<\/ol>\n

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