Vous semblez confondre le mappage de la mémoire avec des fichiers dans des systèmes de fichiers résidant en mémoire, ainsi que d'autres concepts tels que la façon dont les processus conservent l'accès aux fichiers même lorsqu'ils sont déplacés.
Je vais aller question par question pour voir si je peux clarifier les choses.
- Disons que je navigue vers un répertoire de mon système de fichiers et qu'il y a un fichier dans ce répertoire. Est-il possible que ce fichier pointe vers une région de la mémoire principale, au lieu de pointer vers une région du disque?
Il pointe vers la mémoire principale si elle se trouve sur un système de fichiers résidant en mémoire, comme procfs qui est généralement monté sur / proc, ou sysfs qui est sur / sys, ou tmpfs qui est parfois sur / tmp.
- Si cela est possible, est-ce ce que nous appelons un «fichier mappé en mémoire»?
Non. Comme l'a dit stephen-kitt, "mappage de mémoire" fait référence à un moyen d'accéder à un fichier en le "mappant" sur la mémoire principale et en y travaillant plutôt que de lire et d'écrire des morceaux à la fois via des fonctions comme read () et écrire().
- Quelle serait la signification de déplacer un tel fichier dans le système de fichiers (c'est-à-dire de déplacer un tel fichier d'un répertoire vers un autre)? Ce que je comprends, c'est que le fichier étant mappé en mémoire, le ou les processus interagissant avec le fichier écrivent toujours dans une région prédéfinie de la mémoire principale et lorsque nous ouvrons ce fichier (par exemple à l'aide de vim), nous lisons cette région de mémoire principale (donc, aucun disque n'est impliqué). Par conséquent, peu importe où nous déplaçons le fichier, il fonctionnera toujours correctement, n'est-ce pas? Si oui, le déplacement du fichier dans le système de fichiers a-t-il une signification?
Si vous le déplacez dans le même système de fichiers, vous ne faites que déplacer une référence, un inode d'un répertoire à un autre. S'il y a des programmes qui avaient déjà ouvert ce fichier, ils accéderont toujours au même fichier car ils ont déjà l'inode à portée de main via un descripteur de fichier. C'est ce qui s'est produit avec le fichier nom_table.idb que vous avez mentionné dans un commentaire.
- Existe-t-il une commande qui indiquerait si un fichier est mappé en mémoire?
Wossname a déjà répondu à cette question pour les fichiers mappés en mémoire. lsofvous indiquera quels processus ont le fichier mappé en mémoire.
Pour savoir si un fichier se trouve dans un système de fichiers résidant en mémoire, vous pouvez utiliser dfou
mountpour répertorier les systèmes de fichiers et leurs points de montage. Il vous suffit de savoir quels types de systèmes de fichiers résident en mémoire en les recherchant (par exemple dans wikipedia).
- Enfin, si j'ouvre un fichier mappé en mémoire avec vim, y apporte des modifications et que j'enregistre et ferme vim, que se passera-t-il? Mes modifications seront-elles simplement écrites dans la mémoire principale? Si tel est le cas, les autres processus qui utilisent ce fichier verront-ils les modifications que je viens d'apporter? D'après mon expérience, les autres processus n'ont pas vu les modifications que j'ai apportées au fichier lorsque j'ai apporté des modifications au fichier avec vim. Quelle est la raison pour ça?
Personnellement, je n'ai pas utilisé la mmapfonction dans un programme C, mais si je comprends bien le survol man mmapet info mmap, il n'y a aucune magie impliquée dans le maintien de la représentation en mémoire en synchronisation. Dans sa forme de base, l'appel de mmap copie le contenu du fichier en mémoire et msyncest utilisé pour le réécrire de la mémoire sur le disque. Si le fichier sur disque change, rien n'est en place pour le détecter et modifier automatiquement la représentation en mémoire dans tous les processus qui l'ont mappé.
EDIT: Il s'avère que mmap () essaie en fait de garder la représentation en mémoire synchronisée dans certaines conditions. Si la carte est uniquement lue, elle sera synchronisée même lorsque d'autres processus écrivent dans le fichier. S'il est écrit dans (en l'attribuant à la région de mémoire), ce qui se passe dépend du drapeau MAP_SHARED ou MAP_PRIVATE apparemment obligatoire fourni à mmap (). Si MAP_PRIVATE est fourni, la carte se dérobe à partir de la représentation sur disque et cesse d'être synchronisée jusqu'à ce que vous utilisiez msync (). Si MAP_SHARED est fourni, les mises à jour sont rendues visibles aux autres processus qui ont le fichier mappé, ainsi que (bien que cela ne soit pas nécessairement immédiat) la représentation sur disque.
Je viens d'ouvrir vim sur un fichier existant eet d' exécuter la commande :w, tout en ayant inotifywait -m .exécuté dans un autre terminal. Parmi quelques morceaux étranges, c'est la partie importante dont je suis sorti inotifywait.
./ MOVED_FROM e
./ MOVED_TO e~
./ CREATE e
./ OPEN e
./ MODIFY e
./ CLOSE_WRITE,CLOSE e
./ ATTRIB e
./ ATTRIB e
./ DELETE e~
Vim crée un nouveau fichier et supprime l'ancien. Pourquoi cela fait-il au lieu de modifier le fichier est hors de portée de cette question, mais le fait est qu'il s'agit d'un nouveau fichier et donc d'un nouvel inode.
Maintenant, qu'entendez-vous par d'autres processus utilisant ce fichier? Si vous voulez dire les processus qui ont ouvert le fichier pendant que vous le faites, non, ils ne verront pas les modifications. En effet, bien qu'ils aient ouvert un fichier avec le même chemin d'accès, ils ne sont pas le même fichier. Si vous voulez dire les processus qui peuvent ouvrir le fichier après cela, alors oui, ils verront les changements. Ils ouvriront le nouveau fichier que vous avez créé.
Il est important de noter que même si les programmes peuvent sembler avoir un fichier ouvert sur l'interface utilisateur, cela ne signifie pas nécessairement qu'ils gardent le fichier ouvert dans le processus. Vim en est un exemple, comme illustré ci-dessus.