Вы, кажется, путаете отображение памяти с файлами в файловых системах, находящихся в памяти, наряду с другими понятиями, такими как то, как процессы поддерживают доступ к файлам, даже когда они перемещаются.
Я пойду вопрос за вопросом, чтобы посмотреть, смогу ли я все прояснить.
- Допустим, я перехожу к каталогу в моей файловой системе, и в этом каталоге есть файл. Возможно ли, чтобы этот файл указывал на область в основной памяти, а не на область на диске?
Он указывает на основную память, если она находится в файловой системе, находящейся в памяти, например, procfs, которая обычно монтируется в / proc, или sysfs, которая находится в / sys, или tmpfs, которая иногда находится в / tmp.
- Если это возможно, это то, что мы называем «файл с отображением в памяти»?
Нет. Как сказал Стивен-Китт, «отображение памяти» относится к способу доступа к файлу путем «сопоставления» его с основной памятью и работы с ним там, а не для чтения и записи фрагментов одновременно с помощью таких функций, как read () и записывать().
- Каков смысл перемещения такого файла по файловой системе (то есть перенос такого файла из одного каталога в другой)? Насколько я понимаю, поскольку файл отображен в памяти, процесс (ы), взаимодействующий с файлом, всегда записывает в предопределенную область основной памяти, и когда мы открываем этот файл (например, с помощью vim), мы читаем эту область основная память (значит, диск не задействован). Следовательно, независимо от того, куда мы перемещаем файл, он всегда будет работать правильно, верно? Если да, имеет ли какое-либо значение перемещение файла вокруг файловой системы?
Если вы перемещаете его внутри одной и той же файловой системы, вы на самом деле просто перемещаетесь по ссылке, индексу из одного каталога в другой. Если есть программы, которые уже открыли этот файл, они все равно будут обращаться к тому же файлу, потому что у них уже есть inode под дескриптором файла. Это то, что произошло с файлом table_name.idb, который вы упомянули в комментарии.
- Есть ли команда, которая скажет, сопоставлен ли файл с памятью?
Wossname уже ответил на это для отображенных в памяти файлов. lsofскажет вам, какие процессы отображены в памяти файла.
Чтобы узнать, находится ли файл в файловой системе, находящейся в памяти, вы можете использовать dfили
mountдля вывода списка файловых систем и их точек монтирования. Вам просто нужно знать, какие типы файловых систем находятся в памяти, просматривая их (например, в википедии).
- Наконец, если я открою отображенный в памяти файл с помощью vim, внесу в него некоторые изменения и сохраню и закрою vim, что произойдет? Будут ли мои изменения просто записываться в основную память? Если это так, другие процессы, использующие этот файл, увидят изменения, которые я только что сделал? По моему опыту, другие процессы не видели изменений, которые я внес в файл, когда я сделал некоторые изменения в файле с помощью vim. Что является причиной этого?
Лично я не использовал эту mmapфункцию в программе на C, но, насколько я понимаю, из-за скимминга man mmapи info mmapникакой магии не требуется для поддержания представления в памяти в синхронизации. В своей основной форме вызов mmap копирует содержимое файла в память и msyncиспользуется для записи его обратно из памяти на диск. Если файл на диске изменяется, нет ничего, что могло бы обнаружить это и автоматически изменить представление в памяти во всех процессах, которые его отобразили.
РЕДАКТИРОВАТЬ: Оказывается, что mmap () на самом деле пытается синхронизировать представление в памяти при некоторых условиях. Если карта только для чтения, она будет синхронизирована, даже когда другие процессы будут записывать в файл. Если он записан (путем присвоения области памяти), то, что происходит, зависит от того, какой из явно обязательных флагов MAP_SHARED или MAP_PRIVATE предоставлен mmap (). Если указано MAP_PRIVATE, карта разветвляется из представления на диске и перестает синхронизироваться до тех пор, пока вы не используете msync (). Если предоставляется MAP_SHARED, то обновления становятся видимыми для других процессов, которым сопоставлен файл, а также (хотя это не обязательно необходимо) представление на диске.
Я просто открыл vim для существующего файла eи выполнил команду :w, inotifywait -m .запустив другой терминал. Среди некоторых странных моментов, это важная часть, которую я получил inotifywait.
./ MOVED_FROM e
./ MOVED_TO e~
./ CREATE e
./ OPEN e
./ MODIFY e
./ CLOSE_WRITE,CLOSE e
./ ATTRIB e
./ ATTRIB e
./ DELETE e~
Vim создает новый файл и удаляет старый. Почему это происходит вместо изменения файла, выходит за рамки этого вопроса, но дело в том, что это новый файл и, следовательно, новый индекс.
Теперь, что вы подразумеваете под другими процессами, использующими этот файл? Если вы имеете в виду процессы, которые открыли файл во время этого процесса, нет, они не увидят изменений. Это потому, что, хотя они открыли файл с одинаковым путем, они не являются тем же файлом. Если вы имеете в виду процессы, которые могут открыть файл после того, как вы это сделали, то да, они увидят изменения. Они будут открывать новый файл, который вы создали.
Важно отметить, что, хотя программы могут показаться, что файл открыт в пользовательском интерфейсе, это не обязательно означает, что они сохраняют файл открытым в процессе. Vim является примером этого, как показано выше.