Sembra che tu confonda la mappatura della memoria con i file nei filesystem che risiedono nella memoria, insieme ad altri concetti come il modo in cui i processi mantengono l'accesso ai file anche quando vengono spostati.
Vado domanda per domanda per vedere se riesco a chiarire le cose.
- Diciamo che cerco una directory nel mio file system e c'è un file in questa directory. È possibile che questo file punti a un'area nella memoria principale, anziché a un'area nel disco?
Indica la memoria principale se si trova su un file system residente in memoria, come procfs che è tipicamente montato su / proc, o sysfs che è su / sys o tmpfs che a volte è su / tmp.
- Se questo è possibile, è questo che chiamiamo "file mappato in memoria"?
No. Come ha detto Stephen-Kitt, "mappatura della memoria" si riferisce a un modo per accedere a un file "mappandolo" sulla memoria principale e lavorando con esso piuttosto che leggere e scrivere blocchi alla volta tramite funzioni come read () e Scrivi().
- Quale sarebbe il significato di spostare tale file all'interno del file system (ovvero spostare tale file da una directory in un'altra)? Quello che ho capito è che, poiché il file è mappato in memoria, il processo (i) che interagisce con il file scrive sempre in una regione predefinita della memoria principale e quando apriamo quel file (ad esempio usando vim), leggiamo quella regione di memoria principale (quindi, nessun disco è coinvolto). Quindi, indipendentemente da dove spostiamo il file, funzionerà sempre correttamente, giusto? Se sì, lo spostamento del file nel file system ha qualche significato?
Se lo sposti all'interno dello stesso filesystem, stai semplicemente spostando un riferimento, un inode da una directory all'altra. Se ci sono programmi che hanno già aperto questo file, accederanno comunque allo stesso file perché hanno già l'inode a portata di mano tramite un descrittore di file. Questo è ciò che è accaduto con il file table_name.idb che hai citato in un commento.
- Esiste un comando che direbbe se un file è mappato in memoria?
Wossname ha già risposto a questa domanda per i file mappati in memoria. lsofti dirà quali processi hanno il file mappato in memoria.
Per sapere se un file si trova in un filesystem residente in memoria, è possibile utilizzare dfo
mountelencare i filesystem e i loro mountpoint. Hai solo bisogno di sapere quali tipi di filesystem risiedono in memoria cercandoli (ad es. In Wikipedia).
- Infine, se apro un file mappato in memoria con vim, apporto alcune modifiche su di esso e salvo e chiudo vim, cosa accadrà? Le mie modifiche verranno semplicemente scritte nella memoria principale? In tal caso, altri processi che utilizzano questo file vedranno le modifiche che ho appena apportato? Nella mia esperienza, gli altri processi non hanno visto le modifiche che ho apportato al file quando ho apportato alcune modifiche al file con vim. Qual è la ragione di ciò?
Personalmente, non ho usato la mmapfunzione in un programma C, ma come ho capito dallo skimming man mmape info mmapnon c'è magia per mantenere sincronizzata la rappresentazione in memoria. Nella sua forma base, chiamare mmap copia il contenuto del file in memoria e msyncviene usato per riscriverlo dalla memoria al disco. Se il file su disco cambia, non c'è nulla in atto per rilevarlo e modificare automaticamente la rappresentazione in memoria in tutti i processi che lo hanno mappato.
EDIT: Si scopre che mmap () in realtà cerca di mantenere sincronizzata la rappresentazione in memoria in alcune condizioni. Se la mappa viene solo letta, verrà mantenuta sincronizzata anche quando altri processi scrivono nel file. Se è scritto (assegnando alla regione di memoria), ciò che accade dipende da quale flag MAP_SHARED o MAP_PRIVATE apparentemente obbligatori viene fornito a mmap (). Se viene fornito MAP_PRIVATE, la mappa esegue il fork dalla rappresentazione su disco e smette di essere sincronizzata fino a quando non si utilizza msync (). Se viene fornito MAP_SHARED, gli aggiornamenti vengono resi visibili ad altri processi su cui è stato mappato il file, nonché (anche se non necessariamente necessario) la rappresentazione su disco.
Ho appena aperto vim su un file esistente eed eseguito il comando :w, pur avendo inotifywait -m .eseguito in un altro terminale. Tra alcuni bit strani, questa è la parte importante da cui ho avuto 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 nuovo file e rimuove quello vecchio. Perché lo fa invece di modificare il file va oltre lo scopo di questa domanda, ma il punto è che questo è un nuovo file e quindi ha un nuovo inode.
Ora, cosa intendi con altri processi usando questo file? Se intendi processi che avevano aperto il file mentre lo facevi, no non vedranno le modifiche. Questo perché, sebbene abbiano aperto un file con lo stesso percorso, non sono lo stesso file. Se intendi processi che potrebbero aprire il file dopo averlo fatto, allora sì vedranno le modifiche. Apriranno il nuovo file che hai creato.
È importante notare che sebbene i programmi possano sembrare avere un file aperto nell'interfaccia utente, ciò non significa necessariamente che mantengano il file aperto nel processo. Vim ne è un esempio, come mostrato sopra.