Wenn Ihr Python-Programm in eine Datei schreibt, ist die Rückgabe des Funktionsaufrufs   ; sie ist lediglich eine Empfangsbestätigung. Als Entwickler verlassen wir uns auf Abstraktionen, um die komplexen Realitäten der Hardware zu verbergen. Wir schreiben Code, der sich deterministisch und unmittelbar anfühlt, und gehen oft davon aus, dass ein erfolgreicher Funktionsaufruf die physische Unveränderlichkeit der Daten gewährleistet. keine Garantie für die Speicherung  Betrachten Sie dieses einfache Python-Codefragment, das eine Rolle in einem Transaktionsverarbeitungssystem spielt:    Wenn das  transaction_id = "TXN-987654321" # Open a transaction log in text mode with open("/var/log/transactions.log", "a") as log_file: # Write the commitment record log_file.write(f"COMMIT: {transaction_id}\n") print("Transaction recorded") transaction_id = "TXN-987654321" # Open a transaction log in text mode with open("/var/log/transactions.log", "a") as log_file: # Write the commitment record log_file.write(f"COMMIT: {transaction_id}\n") print("Transaction recorded")    Anweisung wird ausgeführt, die Anwendung wird fortgesetzt und geht davon aus, dass die Daten sicher sind. Die Daten sind jedoch weder auf der Festplatte noch im Dateisystem gelandet. Sie haben lediglich einen komplexen Datenaustausch über sechs verschiedene Abstraktionsebenen begonnen, von denen jede ihre eigenen Puffer und Architekturziele verfolgt. print  In diesem Artikel beschreiben wir den technischen Lebenszyklus dieser Datennutzlast, nämlich der Zeichenkette   während sie vom Python-Benutzerbereich bis zum Silizium des SSD übertragen wird. "COMMIT: TXN-987654321\n"  [Schicht 1]: Benutzermodus (Python & Libc)  Der Anwendungspuffer  Unsere Reise beginnt im Prozessspeicher des Python-Interpreters. Wenn Sie   auf eine im Textmodus geöffnete Datei anwenden, führt Python in der Regel nicht sofort einen Systemaufruf aus. Kontextwechsel zum Kernel sind aufwändig. Stattdessen verwendet Python einen Benutzerspeicherpuffer, um Daten zu sammeln. Standardmäßig ist dieser Puffer 8 KB groß, speziell gewählt, um ihn an die Speicherseitengröße des zugrunde liegenden Betriebssystems anzupassen. file.write()  Unsere Nutzdaten befinden sich in diesem RAM-Puffer. Sie gehören vollständig dem Python-Prozess. Wenn die Anwendung abrupt beendet wird, beispielsweise durch ein   -Signal oder einen Segmentierungsfehler, gehen die Daten sofort verloren. Sie haben den Speicherbereich der Anwendung nie verlassen. SIGKILL  The Flush und The Libc Wrapper  Die   -Anweisung beendet den Code und löst ein automatisches   aus. Dies wiederum führt zu einem   . Python gibt nun diese Daten aus und übergibt die Nutzdaten an die systemeigene C-Standardbibliothek, beispielsweise   unter Linux.   dient als standardisierte Schnittstelle zum Kernel. Während C-Funktionen wie   ihre eigenen Benutzerpuffer verwalten, ruft der `flush`-Vorgang von Python typischerweise direkt die Low-Level     auf.   initialisiert die CPU-Register mit der Dateideskriptornummer, dem Zeiger auf den Puffer und der Nutzdatenlänge. Anschließend führt es einen CPU-Befehl aus, beispielsweise   auf x86-64-Architekturen, um den Kernel zu erreichen. with .close() .flush() `glibc` libc fwrite -Funktion write(2) libc SYSCALL  An diesem Punkt überschreiten wir die Grenze vom Benutzermodus in den Kernelmodus.  [Schicht 2]: Die Kernelgrenze (VFS)  Die CPU wechselt in den privilegierten Modus. Der Linux-Kernel verarbeitet die Interruptanforderung, prüft die CPU-Register und identifiziert eine Schreibanforderung an einen Dateideskriptor. Er leitet diese Anforderung an das   weiter. Das VFS dient als Vereinheitlichungsschicht des Kernels. Es stellt eine konsistente API für das System bereit, unabhängig davon, ob der zugrunde liegende Speicher Ext4, XFS, NFS oder eine RAM-Disk ist. virtuelle Dateisystem (VFS)  Das virtuelle Dateisystem (VFS) führt erste Gültigkeitsprüfungen durch, z. B. die Überprüfung von Berechtigungen und Dateideskriptorstatus. Anschließend verwendet es den Dateideskriptor, um den für den Pfad zuständigen Dateisystemtreiber zu ermitteln, in diesem Fall Ext4. Das VFS ruft dann den für diesen Treiber spezifischen Schreibvorgang auf.  [Schicht 3]: Der Seitencache (Optimistische E/A)  Wir sind beim Leistungszentrum des Linux-Speicher-Stacks angekommen: dem   . Seitencache  Unter Linux erfolgt die Datei-E/A grundsätzlich   . Wenn der Ext4-Treiber eine Schreibanforderung empfängt, initiiert er in der Regel keine sofortige Kommunikation mit der Festplatte. Stattdessen bereitet er das Schreiben in den Seitencache vor. Der Seitencache ist ein Bereich des Arbeitsspeichers,   . Es ist anzumerken, dass Ext4 die eigentlichen speicherbezogenen Operationen des Seitencaches im Allgemeinen an das generische Speicherverwaltungssystem des Kernels delegiert. Was dann geschieht, ist Folgendes: speicherabgebildet der dem Zwischenspeichern von Dateidaten dient  Der Kernel verwaltet den Speicher in Einheiten fester Größe, sogenannten   (typischerweise 4 KB in Standard-Linux-Konfigurationen). Da unsere Transaktionsprotokoll-Nutzdaten klein sind (   ), passen sie vollständig in eine einzelne Seite. Der Kernel reserviert (oder findet) die spezifische 4-KB-Seite des Arbeitsspeichers, die dem aktuellen Offset der Datei entspricht. Seiten "COMMIT: TXN-987654321\n"  Es kopiert die Nutzdaten in diese Speicherseite.  Diese Seite wird als   markiert. Eine veränderte Seite bedeutet, dass die Daten im Arbeitsspeicher neuer sind als die Daten im permanenten Speicher. „verändert“    Sobald die Daten in den Arbeitsspeicher kopiert wurden, gibt der Systemaufruf   den   an   zurück, die wiederum an Python zurückkehrt. Entscheidend ist, dass die Anwendung ein Erfolgssignal erhält,   physische Ein-/Ausgabeoperationen stattgefunden haben. Der Kernel   und delegiert den aufwändigen Festplattenzugriff an einen Hintergrundprozess. Die Daten sind derzeit anfällig für einen Kernel-Panic oder einen Stromausfall. Die Rückgabe: write(2) SUCCESS libc bevor priorisiert Durchsatz und Latenz gegenüber sofortiger Datenspeicherung  [Schicht 4]: Das Dateisystem (Ext4 & JBD2)  Die Daten können für längere Zeit im Seitencache verbleiben. Standardmäßig erlaubt Linux, dass geänderte Seiten bis zu 30 Sekunden im Arbeitsspeicher (RAM) gespeichert bleiben. Schließlich initiiert ein Hintergrundprozess des Kernels den Writeback-Prozess, um diese geänderten Seiten zu löschen. Das   muss die Daten nun speichern. Es muss außerdem die zugehörigen Metadaten aktualisieren, wie z. B. die Dateigröße und die Zeiger auf die physischen Blöcke auf der Festplatte. Diese Metadatenstrukturen existieren zunächst nur im Arbeitsspeicher. Um Datenbeschädigung bei einem Systemabsturz zu verhindern, verwendet Ext4 ein Verfahren namens Journaling. Ext4-Dateisystem  Bevor das Dateisystem die Dateistruktur dauerhaft aktualisiert, interagiert Ext4 mit seiner Journaling-Schicht, dem   . Ext4 arbeitet typischerweise im Modus „geordnetes Journaling“. Es orchestriert den Vorgang, indem es in einer bestimmten Reihenfolge separate Schreibanforderungen an die Blockschicht (Schicht 5 – nächster Abschnitt) sendet. JBD2 (Journaling Block Device)    . Zunächst sendet Ext4 eine Anfrage zum Schreiben der eigentlichen Daten an ihren endgültigen Speicherort auf der Festplatte. Dadurch wird sichergestellt, dass die Speicherblöcke gültige Informationen enthalten, bevor Metadatenzeiger darauf verweisen. Schritt 1: Das Schreiben der Daten    . Sobald der Schreibvorgang abgeschlossen ist, sendet JBD2 eine Schreibanforderung für die Metadaten. Dabei wird eine Beschreibung der Änderungen in einen reservierten Ringpuffer auf der Festplatte, das sogenannte Journal, geschrieben. Dieser Eintrag dient als Bestätigung, dass die Dateistruktur erfolgreich aktualisiert wurde. Schritt 2: Journal-Commit    . Abschließend schreibt das Dateisystem die geänderten Metadaten aus dem Arbeitsspeicher in die Inode-Tabellen auf der Festplatte. Sollte das System vor diesem Schritt abstürzen, kann das Betriebssystem das Journal wiederherstellen, um das Dateisystem in einen konsistenten Zustand zurückzuversetzen. Schritt 3: Der Prüfpunkt  [Schicht 5]: Die Blockschicht und der E/A-Scheduler  Das Dateisystem packt seine ausstehenden Daten in eine Struktur, die als   (Block I/O) bezeichnet wird. Diese Struktur wird anschließend an die   übermittelt. Die Blockschicht fungiert als Datenverkehrssteuerung für das Speichersubsystem. Sie optimiert den Ablauf der Anfragen, bevor diese die Hardware erreichen, mithilfe eines   wie MQ-Deadline oder BFQ. Bei hoher Systemlast mit Tausenden kleiner, zufälliger Schreibanfragen fängt der Scheduler diese ab, um die Effizienz zu steigern. Er führt im Allgemeinen zwei Hauptoperationen aus. bio Blockschicht I/O-Schedulers    . Der Scheduler versucht, benachbarte Anfragen zu weniger, aber größeren Operationen zusammenzufassen. Durch die Zusammenführung mehrerer kleiner Schreibvorgänge, die auf zusammenhängende Sektoren der Festplatte abzielen, reduziert das System die Anzahl der einzelnen Befehle, die es an das Gerät senden muss. Zusammenführung von Anfragen    . Der Scheduler ordnet die Warteschlange neu an. Er priorisiert Anfragen, um den Durchsatz des Geräts zu maximieren oder eine faire Behandlung verschiedener laufender Prozesse zu gewährleisten. Neuanordnung von Anfragen  Sobald der Scheduler die Warteschlange organisiert hat, leitet er die Anfrage an den entsprechenden Gerätetreiber weiter, beispielsweise an den   . Dieser Treiber übersetzt die generische Blockanfrage in das von der Hardware benötigte spezifische Protokoll, beispielsweise den über den   übertragenen NVMe-Befehlssatz. NVMe-Treiber PCIe-Bus  [Schicht 6]: Die Hardware (Der SSD-Controller)  Die Nutzdaten durchlaufen den PCIe-Bus und erreichen die SSD. Doch auch innerhalb der Hardware spielt die Pufferung eine entscheidende Rolle. Moderne Enterprise-SSDs fungieren als spezialisierte Computer. Sie nutzen proprietäre Firmware auf Mehrkern-ARM-Prozessoren, um die komplexen physikalischen Prozesse der Datenspeicherung zu steuern.    . Der DRAM-Cache und die Bestätigung  Um die Latenz von NAND-Flash-Speichern zu kaschieren, deren Schreibvorgänge im Vergleich zu den Lesevorgängen langsam sind, speichert der SSD-Controller die Daten zunächst in seinem internen DRAM-Cache. Sobald die Daten diesen Cache erreichen, sendet der Controller eine Bestätigung an das Betriebssystem, dass der Schreibvorgang abgeschlossen ist. In diesem Moment   . Sie liegen auf der Leiterplatte des Laufwerks und nicht auf dem Motherboard des Servers. Hochwertige Enterprise-Laufwerke verfügen über Kondensatoren, die diesen Cache bei einem plötzlichen Stromausfall leeren, Consumer-Laufwerke hingegen besitzen diese Schutzfunktion oft nicht. befinden sich die Daten noch im flüchtigen Speicher   Blitzübersetzung & -löschung  Die Flash Translation Layer (FTL) der SSD übernimmt nun. Da NAND-Flash-Speicher nicht direkt überschrieben werden kann, muss er zunächst in großen Blöcken gelöscht werden. Die FTL ermittelt den optimalen physischen Speicherort für die Daten, um einen gleichmäßigen Verschleiß des Laufwerks zu gewährleisten – ein Prozess, der als Wear Leveling bekannt ist.   Physische Speicherung  Schließlich legt der Controller eine Spannung an die Transistoren im NAND-Chip an. Dadurch ändert sich deren physikalischer Zustand, um die Binärdaten darzustellen.  Erst nach dieser physikalischen Transformation sind die   .  Daten wirklich dauerhaft  Fazit: Den Dauerhaftigkeitsvertrag verstehen  Der Ablauf eines Schreibvorgangs verdeutlicht den bewussten Kompromiss, den Betriebssysteme zwischen Leistung und Sicherheit eingehen. Indem sie es Schichten ermöglichen, Aufgaben zu puffern und zu verzögern, erreichen Systeme einen hohen Durchsatz, doch die Definition von „geschrieben“ wird dadurch flexibler. Wenn eine Anwendung zum Zeitpunkt der Fertigstellung strikte Datensicherheit erfordert und Datenverlust inakzeptabel ist, können sich Entwickler nicht auf das Standardverhalten eines   -Aufrufs auf Anwendungsebene verlassen. write()  Um die Datenpersistenz zu gewährleisten, müssen diese Abstraktionsschichten explizit mit   durchbrochen werden. Dieser Python-   ruft (unter Linux) den Systemaufruf   auf, der das Schreiben der geänderten Seiten ins Dateisystem erzwingt, das Journal speichert, die Block-E/A ausführt und den Standardbefehl `Flush Cache` an den Speichercontroller sendet, um die flüchtigen Puffer der Hardware auf den NAND-Speicher zu leeren. Erst wenn   zurückkehrt, ist der Vorgang endgültig abgeschlossen. os.fsync(fd) Aufruf `fsync` fsync

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Die Anatomie eines Schreibvorgangs

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

HackerNoon Decoded 2024: Wir feiern unsere Gaming-Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

HackerNoon Decoded 2024: Wir feiern unsere Gaming-Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Celebrating Our AI Community!

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps