Les fichiers sont-ils ouverts par des processus chargés dans la RAM?

Les commandes , par exemple sed, sont des programmes et les programmes sont une logique codifiée dans un fichier et ces fichiers se trouvent quelque part sur le disque dur. Cependant, lorsque des commandes sont exécutées, une copie de leurs fichiers du disque dur est placée dans la RAM , où elles prennent vie et peuvent faire des choses et sont appelées processus .

Les processus peuvent utiliser d'autres fichiers, y lire ou y écrire, et s'ils le font, ces fichiers sont appelés fichiers ouverts. Il y a une commande pour répertorier tous les fichiers ouverts par tous les processus en cours d' exécution: lsof.

OK, donc ce que je me demande, c'est si la double vie d'une commande, une sur le disque dur, l'autre dans la RAM est également vraie pour d'autres types de fichiers, par exemple ceux qui n'ont pas de logique programmée, mais sont simplement des conteneurs pour Les données.

Mon hypothèse est que les fichiers ouverts par des processus sont également chargés dans la RAM. Je ne sais pas si c'est vrai, c'est juste une intuition.

S'il vous plaît, quelqu'un pourrait-il comprendre cela?

Cependant, lorsque des commandes sont exécutées, une copie de leurs fichiers depuis le disque dur est placée dans la RAM,

C'est faux (en général). Lorsqu'un programme est exécuté (via execve (2) ...), le processus (exécutant ce programme) change son espace d'adressage virtuel et le noyau reconfigure la MMU à cet effet. Lisez aussi la mémoire virtuelle . Notez que les programmes d'application peuvent changer leur espace d'adressage virtuel en utilisant mmap (2) & munmap& mprotect (2) , également utilisé par l' éditeur de liens dynamique (voir ld-linux (8) ). Voir aussi madvise (2) & posix_fadvise (2) & mlock (2) .

Les futures erreurs de page seront traitées par le noyau pour charger (paresseusement) les pages du fichier exécutable. Lisez aussi à propos de la raclée .

Le noyau maintient un grand cache de pages . Lisez également sur la copie sur écriture . Voir aussi readahead (2) .

OK, donc ce que je me demande, c'est si la double vie d'une commande, une sur le disque dur, l'autre dans la RAM est également vraie pour d'autres types de fichiers, par exemple ceux qui n'ont pas de logique programmée, mais sont simplement des conteneurs pour Les données.

Pour les appels système comme read (2) & write (2), le cache de page est également utilisé. Si les données à lire s'y trouvent, aucune E / S disque ne sera effectuée. Si le disque IO est nécessaire, les données lues seraient très probablement placées dans le cache de page. Donc, dans la pratique, si vous exécutez la même commande deux fois, il peut arriver qu'aucune E / S physique ne soit effectuée sur le disque la deuxième fois (si vous avez un ancien disque dur rotatif - pas un SSD - vous pourriez l'entendre; ou observez attentivement la LED de votre disque dur).

Je recommande de lire un livre comme Operating Systems: Three Easy Pieces (téléchargeable gratuitement, un fichier PDF par chapitre) qui explique tout cela.

Voir aussi Linux Ate Mes RAM commandes et courir comme xosview, top, htopou cat /proc/self/mapsou cat /proc/$$/maps(voir proc (5) ).

PS. Je me concentre sur Linux, mais d'autres systèmes d'exploitation ont également une mémoire virtuelle et un cache de pages.

Non, un fichier n'est pas lu automatiquement en mémoire en l'ouvrant. Ce serait terriblement inefficace. sed, par exemple, lit son entrée ligne par ligne, comme le font de nombreux autres outils Unix. Il doit rarement conserver plus que la ligne actuelle en mémoire.

Avec awkc'est la même chose. Il lit un enregistrement à la fois, qui par défaut est une ligne. Si vous stockez des parties des données d'entrée dans des variables, ce sera supplémentaire, bien sûr ¹ .

Certaines personnes ont l'habitude de faire des choses comme

for line in $(cat file); do ...; done

Étant donné que le shell devra étendre la $(cat file)substitution de commande complètement avant d' exécuter même la première itération de la forboucle, ce sera lu toute la fileen mémoire (dans la mémoire utilisée par le shell d' exécuter la forboucle). C'est un peu idiot et aussi inélégant. Au lieu de cela, on devrait faire

while IFS= read -r line; do ...; done <file

Cela traitera fileligne par ligne (mais lisez bien Comprendre "IFS = read -r line" ).

Le traitement des fichiers ligne par ligne dans le shell n'est cependant que rarement nécessaire, car la plupart des utilitaires sont de toute façon orientés ligne (voir Pourquoi l'utilisation d'une boucle shell pour traiter du texte est-elle considérée comme une mauvaise pratique? ).

Je travaille en bioinformatique, et lors du traitement d'énormes quantités de données génomiques, je ne serais pas en mesure de faire grand-chose à moins de ne conserver que les bits des données qui étaient absolument nécessaires en mémoire. Par exemple, lorsque j'ai besoin de supprimer les bits de données qui pourraient être utilisés pour identifier des individus d'un ensemble de données de 1 téraoctet contenant des variantes d'ADN dans un fichier VCF (car ce type de données ne peut pas être rendu public), je le fais ligne par ligne traitement avec un awkprogramme simple (ceci est possible car le format VCF est orienté ligne). Je ne lis pas le fichier en mémoire, je ne le traite pas et je le réécris! Si le fichier était compressé, je le ferais passer zcatou gzip -d -c, qui, depuis le gziptraitement en continu des données, ne lirait pas non plus le fichier entier en mémoire.

Même avec des formats de fichiers qui ne sont pas orientés ligne, comme JSON ou XML, il existe des analyseurs de flux qui permettent de traiter des fichiers énormes sans tout stocker dans la RAM.

Avec les exécutables, c'est un peu plus compliqué car les bibliothèques partagées peuvent être chargées à la demande et / ou être partagées entre les processus (voir Chargement des bibliothèques partagées et utilisation de la RAM , par exemple).

La mise en cache est quelque chose que je n'ai pas mentionné ici. Il s'agit de l'utilisation de la RAM pour stocker des données fréquemment consultées. Les fichiers plus petits (par exemple les exécutables) peuvent être mis en cache par le système d'exploitation dans l'espoir que l'utilisateur leur fera de nombreuses références. Outre la première lecture du fichier, les accès ultérieurs seront effectués sur la RAM plutôt que sur le disque. La mise en cache, comme la mise en mémoire tampon des entrées et des sorties, est généralement largement transparente pour l'utilisateur et la quantité de mémoire utilisée pour mettre en cache les choses peut changer dynamiquement en fonction de la quantité de RAM allouée par les applications, etc.

¹ _{Techniquement, la plupart des programmes lisent probablement une partie des données d'entrée à la fois, soit en utilisant une mise en mémoire tampon explicite, soit implicitement via la mise en mémoire tampon des bibliothèques d'E / S standard, puis en présentant cette partie ligne par ligne au code de l'utilisateur. Il est beaucoup plus efficace de lire un multiple de la taille de bloc du disque que par exemple un caractère à la fois. Cependant, cette taille de bloc sera rarement supérieure à une poignée de kilo-octets.}

Non. Bien que les concerts de RAM soient fantastiques ces jours-ci, il fut un temps où la RAM était une ressource très limitée (j'ai appris la programmation sur un VAX 11/750 avec 2 Mo de RAM) et la seule chose en RAM était un exécutable actif et des pages de données. des processus actifs et des données de fichier qui étaient dans le cache de tampon.
Le cache de tampon a été vidé et les pages de données ont été échangées. Et souvent à certains moments. Les pages exécutables en lecture seule ont été écrasées et les tables de pages marquées, donc si le programme touchait à nouveau ces pages, elles étaient paginées à partir du système de fichiers. Les données ont été paginées à partir du swap. Comme indiqué ci-dessus, la bibliothèque STDIO a extrait les données en blocs et a été obtenue par le programme selon les besoins: fgetc, fgets, fread, etc. Avec mmap, un fichier peut être mappé dans l'espace d'adressage d'un processus, comme c'est le cas avec objets de bibliothèque partagée ou même des fichiers normaux. Oui, vous pouvez avoir un certain degré de contrôle si c'est dans la RAM ou non (mlock), mais cela ne va que jusqu'à présent (voir la section code d'erreur de mlock).