Lorsqu'un programme Python écrit dans un fichier, le retour de cette fonction   ; il s'agit simplement d'un accusé de réception. En tant que développeurs, nous nous appuyons sur des abstractions de haut niveau pour masquer la complexité du matériel. Nous écrivons du code qui semble déterministe et instantané, en supposant souvent qu'un appel de fonction réussi équivaut à un enregistrement physique permanent. ne garantit pas l'enregistrement  Prenons l'exemple de ce simple extrait de code Python qui joue un rôle dans un système de traitement des transactions :    Quand cela  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")  L'instruction   s'exécute, l'application reprend son fonctionnement, partant du principe que les données sont intactes. Or, les données n'ont pas encore été écrites sur le disque. Elles n'ont même pas encore atteint le système de fichiers. Elles ont simplement entamé un processus complexe à travers six couches d'abstraction distinctes, chacune avec ses propres tampons et objectifs architecturaux. print  Dans cet article, nous décrirons le cycle de vie technique de cette charge utile de données, à savoir la chaîne   depuis l’espace utilisateur Python jusqu’au silicium du SSD. "COMMIT: TXN-987654321\n"  [Couche 1] : Espace utilisateur (Python et Libc)  Le tampon d'application  Notre exploration commence dans la mémoire du processus de l'interpréteur Python. Lorsque vous appelez   sur un fichier ouvert en mode texte, Python n'effectue généralement pas d'appel système immédiat. Les changements de contexte vers le noyau sont coûteux. Python utilise donc un tampon en espace utilisateur pour accumuler les données. Par défaut, ce tampon a une taille de 8 Ko, choisie spécifiquement pour correspondre à la taille des pages mémoire du système d'exploitation sous-jacent. file.write()  Nos données sont stockées dans cette mémoire tampon RAM. Elles appartiennent entièrement au processus Python. Si l'application s'arrête brutalement, par exemple suite à un signal   ou une erreur de segmentation, les données sont instantanément perdues. Elles n'ont jamais quitté l'espace mémoire de l'application. SIGKILL  Le Flush et le wrapper Libc  L'instruction   conclut l'exécution et déclenche un appel automatique   . Ce dernier déclenche ensuite un appel à `   `. Python éjecte alors ces données et transmet la charge utile à la bibliothèque standard C du système, telle que   sous Linux.   sert d'interface standardisée avec le noyau. Alors que les fonctions C comme   gèrent leurs propres tampons en espace utilisateur, l'opération `flush()` de Python appelle généralement directement la   de bas niveau   `.   configure les registres du processeur avec le numéro du descripteur de fichier, le pointeur vers le tampon et la longueur de la charge utile. Elle exécute ensuite une instruction processeur, telle que   sur les architectures x86-64, pour intercepter l'appel au noyau. with .close() .flush() glibc libc fwrite fonction write(2) libc SYSCALL  À ce stade, nous franchissons la frontière entre l'espace utilisateur et l'espace noyau.  [Couche 2] : La limite du noyau (VFS)  Le processeur passe en mode privilégié. Le noyau Linux traite l'interruption, vérifie les registres du processeur et identifie une requête d'écriture sur un descripteur de fichier. Il transmet ensuite cette requête au   . Le VFS sert de couche d'unification du noyau. Il fournit une API cohérente pour le système, quel que soit le système de stockage sous-jacent : Ext4, XFS, NFS ou disque RAM. système de fichiers virtuel (VFS)  Le système de fichiers virtuel (VFS) effectue des vérifications initiales de validité, telles que la vérification des permissions et de l'état du descripteur de fichier. Il utilise ensuite le descripteur de fichier pour localiser le pilote de système de fichiers spécifique au chemin d'accès, ici Ext4. Le VFS lance alors l'opération d'écriture propre à ce pilote.  [Couche 3] : Le cache de pages (E/S optimistes)  Nous voici arrivés au cœur même de la performance de la pile de stockage Linux : le   . cache de pages  Sous Linux, les entrées/sorties de fichiers sont fondamentalement   . Lorsque le pilote Ext4 reçoit une requête d'écriture, il n'initie généralement pas de communication immédiate avec le disque. Au lieu de cela, il se prépare à écrire dans le cache de pages. Le cache de pages est une portion de la RAM système   . Il est à noter qu'Ext4 délègue généralement les opérations mémoire liées au cache de pages au sous-système de gestion de la mémoire du noyau. La suite des opérations est la suivante : mappées en mémoire dédiée à la mise en cache des données de fichiers  Le noyau gère la mémoire par unités de taille fixe appelées   (généralement 4 Ko sur les configurations Linux standard). Comme la charge utile de notre journal des transactions est courte (   ), elle tient entièrement dans une seule page. Le noyau alloue (ou localise) la page de RAM de 4 Ko correspondant à la position actuelle du fichier. pages "COMMIT: TXN-987654321\n"  Il copie les données utiles dans cette page mémoire.  Cela marque cette page comme   . Une page modifiée signifie que les données en mémoire vive sont plus récentes que celles stockées sur le support de stockage permanent. « modifiée »    Une fois les données copiées en RAM, l’appel système   renvoie   à   , qui les transmet à Python. Point crucial, l’application reçoit ce signal de succès   toute opération d’entrée/sortie physique. Le noyau   des données, en confiant l’opération disque, plus coûteuse, à un processus en arrière-plan. Les données sont actuellement vulnérables à un plantage du noyau ou à une coupure de courant. Retour : write(2) SUCCESS libc avant privilégie le débit et la latence à la persistance immédiate  [Couche 4] : Le système de fichiers (Ext4 et JBD2)  Les données peuvent résider dans le cache de pages pendant une durée significative. Par défaut, Linux autorise la persistance des pages modifiées en mémoire vive (RAM) pendant 30 secondes maximum. Un processus d'arrière-plan du noyau lance ensuite l'écriture automatique pour nettoyer ces pages. Le   doit alors enregistrer les données et mettre à jour les métadonnées associées, telles que la taille du fichier et les pointeurs vers les blocs physiques sur le disque. Ces métadonnées existent initialement uniquement en mémoire système. Pour éviter toute corruption en cas de panne, Ext4 utilise une technique appelée journalisation. système de fichiers Ext4  Avant que le système de fichiers ne mette à jour définitivement la structure des fichiers, Ext4 interagit avec sa couche de journalisation, le   . Ext4 fonctionne généralement en mode de « journalisation ordonnée ». Il orchestre l'opération en soumettant des requêtes d'écriture distinctes à la couche de blocs (couche 5 – section suivante) selon une séquence spécifique. JBD2 (Journaling Block Device)    . Ext4 commence par soumettre une requête pour écrire les données à leur emplacement final sur le disque. Cela garantit que les blocs de stockage contiennent des informations valides avant que des pointeurs de métadonnées ne les référencent. Étape 1 : Écriture des données    . Une fois l’écriture des données terminée, JBD2 soumet une requête d’écriture pour les métadonnées. Il enregistre une description des modifications dans une mémoire tampon circulaire réservée sur le disque, appelée journal. Cette entrée constitue une « validation » attestant que la structure du fichier est bien mise à jour. Étape 2 : Validation dans le journal    . Enfin, le système de fichiers transfère les métadonnées modifiées de la mémoire système vers leur emplacement définitif dans les tables d’inodes sur le disque. Si le système plante avant cette étape, le système d’exploitation peut relire le journal pour restaurer le système de fichiers à un état cohérent. Étape 3 : Le point de contrôle  [Couche 5] : La couche bloc et le planificateur d'E/S  Le système de fichiers regroupe ses données en attente dans une structure appelée   (E/S par blocs). Il soumet ensuite cette structure à la   . Cette dernière fait office de contrôleur de trafic pour le sous-système de stockage. Elle optimise le flux des requêtes avant qu'elles n'atteignent le matériel grâce à un   , tel que MQ-Deadline ou BFQ. Si le système est fortement sollicité par des milliers de petites requêtes d'écriture aléatoires, le planificateur les intercepte afin d'améliorer l'efficacité. Il effectue généralement deux opérations clés. bio couche blocs planificateur d'E/S    . Le planificateur tente de regrouper les requêtes adjacentes en un nombre réduit d'opérations plus importantes. En fusionnant plusieurs petites écritures ciblant des secteurs contigus sur le disque, le système réduit le nombre de commandes individuelles qu'il doit envoyer au périphérique. Fusion des requêtes    . Le planificateur réorganise également la file d'attente. Il priorise les requêtes afin d'optimiser le débit du périphérique ou de garantir une répartition équitable entre les différents processus en cours d'exécution. Réorganisation des requêtes  Une fois la file d'attente organisée, le planificateur transmet la requête au pilote de périphérique concerné, tel que le   . Ce pilote traduit la requête de bloc générique en un protocole spécifique requis par le matériel, comme le jeu de commandes NVMe transmis sur le   . pilote NVMe bus PCIe  [Couche 6] : Le matériel (le contrôleur SSD)  Les données transitent par le bus PCIe et atteignent le SSD. Cependant, même au sein du matériel, la mise en mémoire tampon joue un rôle crucial. Les SSD d'entreprise modernes fonctionnent comme des ordinateurs spécialisés. Ils exécutent un firmware propriétaire sur des processeurs ARM multicœurs pour gérer la complexité des opérations de stockage des données.    . Cache DRAM et accusé de réception  Pour masquer la latence de la mémoire flash NAND, plus lente en écriture qu'en lecture, le contrôleur SSD stocke initialement les données dans son cache DRAM interne. Une fois les données dans ce cache, le contrôleur envoie un accusé de réception au système d'exploitation pour confirmer la fin de l'écriture. À cette nanoseconde précise,   . Elles résident sur le circuit imprimé du disque et non sur la carte mère du serveur. Les disques haut de gamme pour entreprises intègrent des condensateurs pour vider ce cache en cas de coupure de courant, mais les disques grand public sont souvent dépourvus de cette protection. les données sont encore en mémoire volatile   Traduction et effacement Flash  La couche de traduction Flash (FTL) du SSD prend alors le relais. La mémoire flash NAND ne pouvant être écrasée directement, elle doit d'abord être effacée par blocs importants. La FTL détermine l'emplacement physique optimal des données afin de garantir une usure uniforme sur le disque, un processus appelé nivellement d'usure.   Stockage physique  Enfin, le contrôleur applique une tension aux transistors de la puce NAND. Cela modifie leur état physique pour représenter les données binaires.  Ce n’est qu’après cette transformation physique que les   .  données deviennent véritablement persistantes  Conclusion : Comprendre le contrat de durabilité  Le processus d'écriture met en lumière le compromis explicite que font les systèmes d'exploitation entre performance et sécurité. En permettant aux différentes couches de mettre en mémoire tampon et de différer les tâches, les systèmes atteignent un débit élevé, mais la définition de « données écrites » devient floue. Si une application exige une stricte durabilité des données au moment de la fin de l'écriture, où toute perte de données est inacceptable, les développeurs ne peuvent pas se fier au comportement par défaut d'un appel à la fonction   ` au niveau de l'application. write()  Pour garantir la persistance des données, il est nécessaire de traverser explicitement ces couches d'abstraction à l'aide de   . Cet   Python invoque l'appel système   (sous Linux), qui force l'écriture des pages modifiées sur le système de fichiers, valide le journal, distribue les E/S de blocs et envoie une commande standard de « vidage du cache » au contrôleur de stockage, exigeant ainsi que le matériel vide ses tampons volatils sur la mémoire NAND. Le processus n'est véritablement terminé qu'une fois   renvoyé. os.fsync(fd) appel `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.

Anatomie d'une opération d'écriture

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps