Você parece estar confundindo mapeamento de memória com arquivos em sistemas de arquivos que residem na memória, além de outros conceitos como como os processos mantêm o acesso aos arquivos, mesmo quando eles são movidos.
Vou perguntar pergunta por pergunta para ver se consigo esclarecer as coisas.
- Digamos que eu procure um diretório no meu sistema de arquivos e haja um arquivo nesse diretório. É possível que esse arquivo aponte para uma região na memória principal, em vez de apontar para uma região no disco?
Ele aponta para a memória principal se estiver em um sistema de arquivos que resida na memória, como procfs que normalmente é montado em / proc, ou sysfs que está em / sys ou tmpfs que às vezes está em / tmp.
- Se isso for possível, é isso que chamamos de 'arquivo mapeado na memória'?
Não. Como stephen-kitt disse, "mapeamento de memória" refere-se a uma maneira de acessar um arquivo "mapeando" na memória principal e trabalhando com ele lá, em vez de ler e escrever pedaços de cada vez por meio de funções como read () e Escreva().
- Qual seria o significado de mover esse arquivo pelo sistema de arquivos (ou seja, mover esse arquivo de um diretório para outro)? O que eu entendo é que, como o arquivo é mapeado na memória, o (s) processo (s) interagindo com o arquivo sempre grava em uma região predefinida da memória principal e, quando abrimos esse arquivo (por exemplo, usando o vim), lemos essa região de memória principal (portanto, nenhum disco está envolvido). Portanto, não importa para onde movemos o arquivo, ele sempre funcionará corretamente, certo? Se sim, mover o arquivo pelo sistema de arquivos tem algum significado?
Se você movê-lo dentro do mesmo sistema de arquivos, você está apenas movendo uma referência, um inode de um diretório para outro. Se houver programas que já tiveram esse arquivo aberto, eles ainda estarão acessando o mesmo arquivo porque já têm o inode em mãos por meio de um descritor de arquivo. Foi o que aconteceu com o arquivo table_name.idb que você mencionou em um comentário.
- Existe um comando que informa se um arquivo está mapeado na memória?
O Wossname já respondeu isso para arquivos mapeados na memória. lsofinformará quais processos têm o arquivo mapeado na memória.
Para saber se um arquivo está em um sistema de arquivos que reside na memória, você pode usar dfou
mountpara listar os sistemas de arquivos e seus pontos de montagem. Você só precisa saber quais tipos de sistemas de arquivos residem na memória pesquisando-os (por exemplo, na wikipedia).
- Finalmente, se eu abrir um arquivo mapeado na memória com o vim, faça algumas alterações e salve e feche o vim, o que acontecerá? Minhas alterações serão gravadas na memória principal? Se for esse o caso, outros processos que usam esse arquivo verão as alterações que acabei de fazer? Na minha experiência, os outros processos não viram as alterações que fiz no arquivo quando fiz algumas alterações no arquivo com o vim. Qual é a razão para isto?
Pessoalmente, eu não usei a mmapfunção em um programa em C, mas como eu a entendo por skimming man mmapeinfo mmap , não há mágica envolvida em manter a representação na memória em sincronia. Em sua forma básica, chamar mmap copia o conteúdo do arquivo para a memória e msyncé usado para gravá-lo da memória para o disco. Se o arquivo em disco for alterado, não há nada para detectá-lo e modificar automaticamente a representação na memória em todos os processos que o mapearam.
EDIT: Acontece que mmap () realmente tenta manter a representação na memória sincronizada sob algumas condições. Se o mapa for apenas lido, ele será mantido sincronizado, mesmo quando outros processos forem gravados no arquivo. Se for gravado (atribuindo à região da memória), o que acontecerá depende de qual sinalizador MAP_SHARED ou MAP_PRIVATE aparentemente obrigatório é fornecido ao mmap (). Se MAP_PRIVATE for fornecido, o mapa bifurca-se da representação em disco e deixa de estar sincronizado até você usar msync (). Se MAP_SHARED for fornecido, as atualizações serão visíveis para outros processos que têm o arquivo mapeado, bem como (embora isso não seja necessariamente imediato) a representação em disco.
Acabei de abrir o vim em um arquivo existente ee executei o comando :wenquanto inotifywait -m .rodava em outro terminal. Entre alguns trechos estranhos, essa é a parte importante de que recebi inotifywait.
./ MOVED_FROM e
./ MOVED_TO e~
./ CREATE e
./ OPEN e
./ MODIFY e
./ CLOSE_WRITE,CLOSE e
./ ATTRIB e
./ ATTRIB e
./ DELETE e~
O Vim cria um novo arquivo e remove o antigo. Por que isso ocorre em vez de modificar o arquivo está além do escopo desta pergunta, mas o ponto é que este é um novo arquivo e, portanto, possui um novo inode.
Agora, o que você quer dizer com outros processos usando esse arquivo? Se você quer dizer processos que tiveram o arquivo aberto enquanto você fazia isso, eles não verão as alterações. Isso ocorre porque, embora eles tenham aberto um arquivo com o mesmo caminho, eles não são o mesmo arquivo. Se você quer dizer processos que podem abrir o arquivo depois de fazer isso, sim, eles verão as alterações. Eles abrirão o novo arquivo que você criou.
É importante observar que, embora os programas pareçam ter um arquivo aberto na interface do usuário, isso não significa necessariamente que eles mantêm o arquivo aberto no processo. O Vim é um exemplo disso, como mostrado acima.