Ah, wieder mal die Sync-Sache.
Mit der sync/async Hölle komm ich immer noch nicht ganz klar... also was genau jetzt sync und async ist...
Programme können sich aussuchen, ob sie synchron oder asynchron schreiben.
Ein async Schreibvorgang ist aus Programmsicht typischerweise praktisch sofort fertig, nämlich dann, wenn das OS die zu schreibenden Daten übernommen hat. Im RAM (Cache). Wann das OS tatsächlich anstößt, dass die Daten auf Platte geschrieben werden, oder ob überhaupt, steht in den Sternen. Falls die Platte einen Schreibcache hat, wiederholt sich das Spiel auf der Ebene noch einmal – auch deren Controller übernimmt die Daten dann zunächst einmal nur in den Cache und schreibt das raus, wann's die Firmware halt freut. Usw.
Vorteile: flott. Solang nicht grad die Caches voll sind, passiert alles im RAM, tatsächlich geschrieben wird dann in Ruhe im Hintergrund. OS und Controller können Schreibvorgänge nach Belieben zusammenfassen und umordnen. HDDs sind z. B. viel glücklicher, wenn sie am Stück schreiben dürfen (wenige Seeks), SSDs, wenn sie genug zusammenbekommen, dass sie in ganzen (internen) Blöcken schreiben dürfen bzw. den Schreibvorgang maximal parallelisieren können. Länger halten tun sie dann auch, weil sie nicht für läppische 4K einen ganzen Block löschen und schreiben müssen.
Nachteil: Wenn irgendwas is, bevor die Daten auf der Platte gelandet sind, sind sie weg. Und weil man sich noch nicht einmal darauf verlassen kann, in welcher Reihenfolge Schreibvorgänge durchgeführt werden, hat man dann einen wirren Mix aus Alt und Neu. Wenn das z. B. mit Dateisystemmetadaten passiert, ist das ganze Dateisystem ex.
Ein sync Schreibvorgang blockiert die Programmausführung, bis die Daten tatsächlich auf der Platte sind. Wenn der "Ok!" zurückmeldet, dann hat das Hand und Fuß.
In der Praxis mischt man das auch. Also wenn z. B. ein Dokument gespeichert wird, alle Schreibvorgänge die dafür nötig sind async, aber dann wenn alles fertig ist, ein separater Sync-Befehl, der sich nur auf die Datei bezieht. Und erst wenn der sagt, erledigt, Rückmeldung an den User, dass erfolgreich gespeichert wurde. So kriegt man relativ billig Transaktionen.
Vorteile: Man sich darauf verlassen, dass das Zeug garantiert gespeichert ist. Damit werden die Konsistenzgarantien moderner Dateisysteme und Datenbanken erst möglich.
Nachteile: Damit fallen sämtliche Optimierungsmöglichkeiten oben weg. Schleicht wie die Sau. So, 100 MB/s sind selbst für eine NVMe ein guter Wert und 10 MB/s jetzt auch kein Schock. Dazu write amplification, d. h. die müssen ein Vielfaches der Nutzdaten schreiben. Bye-bye TBW. HDDs stecken das teilweise besser weg (solange sie nicht zu viel seeken müssen).
Es gibt immer wieder Disks, die Syncs einfach ignorieren (entweder weil buggy oder um in Performance-technisch gut dazustehen) . Datenverlust vorprogrammiert. PLP-Disks können Syncs in gewissen Grenzen "legal" ignorieren; schließlich können sie garantieren dass die Daten auf dem Flash landen – selbst wenn der Host rundherum in Flammen steht. Allerdings sind die Caps jetzt nicht groß, detto der Schreibcache; es geht also nur mit kleinen Schreibzugriffen, die man binnen Sekundenbruchteilen in Sicherheit bringen kann. Da die meisten sync writes klein sind, und man sich ja bemüht, sie nur einzusetzen wenn nötig, klappt das trotzdem ganz gut.
Auf einem Consumer-Desktop spielen sync Schreibzugriffe nur eine sehr kleine Rolle. Ein paar Sekunden Datenverlust werden einfach in Kauf genommen, solange nur das Dateisystem ganz bleibt. Is auch ok, bei einem Einzelbenutzersystem weiß man ja auch normalerweise, was offen war / was man jetzt noch einmal machen muss. Bzw. wird generell weniger geschrieben.
Aber z. B. ZFS schreibt viel sync (weil eben Datensicherheit an oberster Stelle steht), Proxmox detto (Cluster-Konsistenz etc.), Ceph schreibt praktisch nur syncron. Datenbanken detto.
Falls wer ein Debian- (Ubuntu-, Mint-, ...) System hat, apt/dpkg sind da sehr konservativ. apt dist-upgrade
schleicht auf den meisten Consumer-SSDs, weil die nur auf async getuned sind.
