Parece confundir la asignación de memoria con archivos en sistemas de archivos que residen en memoria, junto con otros conceptos como cómo los procesos mantienen el acceso a los archivos incluso cuando se mueven.
Iré pregunta por pregunta para ver si puedo aclarar las cosas.
- Digamos que busco un directorio en mi sistema de archivos y hay un archivo en este directorio. ¿Es posible que este archivo apunte a una región en la memoria principal, en lugar de apuntar a una región en el disco?
Apunta a la memoria principal si está en un sistema de archivos que reside en la memoria, como procfs que normalmente está montado en / proc, o sysfs que está en / sys, o tmpfs que a veces está en / tmp.
- Si esto es posible, ¿es esto lo que llamamos 'archivo mapeado en memoria'?
No. Como dijo stephen-kitt, "mapeo de memoria" se refiere a una forma de acceder a un archivo "mapeándolo" en la memoria principal y trabajando con él allí en lugar de leer y escribir fragmentos a la vez a través de funciones como read () y escribir().
- ¿Cuál sería el significado de mover dicho archivo alrededor del sistema de archivos (es decir, mover dicho archivo de un directorio a otro)? Lo que entiendo es que, dado que el archivo está mapeado en memoria, los procesos que interactúan con el archivo siempre escriben en una región predefinida de la memoria principal, y cuando abrimos ese archivo (por ejemplo, usando vim), leemos esa región de memoria principal (por lo tanto, no hay disco involucrado). Por lo tanto, no importa dónde muevamos el archivo, siempre funcionará correctamente, ¿verdad? En caso afirmativo, ¿tiene algún sentido mover el archivo por el sistema de archivos?
Si lo mueve dentro del mismo sistema de archivos, realmente solo se está moviendo alrededor de una referencia, un inodo de un directorio a otro. Si hay programas que ya tenían este archivo abierto, seguirán accediendo al mismo archivo porque ya tienen el inodo a la mano a través de un descriptor de archivo. Esto es lo que sucedió con el archivo table_name.idb que mencionaste en un comentario.
- ¿Hay un comando que diga si un archivo está mapeado en memoria?
Wossname ya respondió esto para los archivos mapeados en memoria. lsofle dirá qué procesos tienen el archivo mapeado en memoria.
Para saber si un archivo está en un sistema de archivos que reside en la memoria, puede usar dfo
mountpara enumerar los sistemas de archivos y sus puntos de montaje. Solo necesita saber qué tipos de sistemas de archivos residen en la memoria buscándolos (por ejemplo, en wikipedia).
- Finalmente, si abro un archivo mapeado en memoria con vim, hago algunos cambios y guardo y cierro vim, ¿qué sucederá? ¿Mis cambios simplemente se escribirán en la memoria principal? Si ese es el caso, ¿otros procesos que usan este archivo verán los cambios que acabo de hacer? En mi experiencia, los otros procesos no vieron los cambios que hice en el archivo cuando hice algunos cambios en el archivo con vim. ¿Cuál es la razón para esto?
Personalmente, no he usado la mmapfunción en un programa en C, pero como la entiendo por descremado man mmapy info mmap, no hay magia involucrada en mantener la representación en memoria sincronizada. En su forma básica, llamar a mmap copia el contenido del archivo a la memoria y msyncse utiliza para volver a escribirlo desde la memoria al disco. Si el archivo en el disco cambia, no hay nada en el lugar para detectarlo y modificar automáticamente la representación en memoria en todos los procesos que lo mapearon.
EDITAR: Resulta que mmap () en realidad intenta mantener sincronizada la representación en memoria en algunas condiciones. Si el mapa solo se lee, se mantendrá sincronizado incluso cuando otros procesos escriban en el archivo. Si se escribe en (asignando a la región de memoria), lo que sucede depende de cuál de los indicadores MAP_SHARED o MAP_PRIVATE aparentemente obligatorios se proporciona a mmap (). Si se proporciona MAP_PRIVATE, el mapa se bifurca desde la representación en disco y deja de estar sincronizado hasta que use msync (). Si se proporciona MAP_SHARED, las actualizaciones se hacen visibles para otros procesos que tienen el archivo asignado, así como (aunque esto no es necesariamente inmediato) la representación en el disco.
Acabo de abrir vim en un archivo existente ey ejecuté el comando :w, mientras lo inotifywait -m .ejecutaba en otra terminal. Entre algunas partes extrañas, esta es la parte importante que obtuve inotifywait.
./ MOVED_FROM e
./ MOVED_TO e~
./ CREATE e
./ OPEN e
./ MODIFY e
./ CLOSE_WRITE,CLOSE e
./ ATTRIB e
./ ATTRIB e
./ DELETE e~
Vim crea un nuevo archivo y elimina el anterior. Por qué hace esto en lugar de modificar el archivo está más allá del alcance de esta pregunta, pero el punto es que este es un archivo nuevo y, por lo tanto, tiene un nuevo inodo.
Ahora, ¿qué quieres decir con otros procesos que usan este archivo? Si te refieres a procesos que tenían el archivo abierto mientras estabas haciendo esto, no, no verán los cambios. Esto se debe a que, aunque abrieron un archivo con la misma ruta, no son el mismo archivo. Si te refieres a procesos que pueden abrir el archivo después de hacer esto, entonces sí, verán los cambios. Abrirán el nuevo archivo que creaste.
Es importante tener en cuenta que aunque los programas pueden tener un archivo abierto en la interfaz de usuario, eso no significa necesariamente que mantengan el archivo abierto en el proceso. Vim es un ejemplo de esto, como se muestra arriba.