Mmap():如果底层文件发生变化(收缩)会发生什么

mmap(): what happens if underlying file changes (shrinks)?

本文关键字:变化 什么 收缩 如果 Mmap 文件      更新时间:2023-10-16

如果使用mmap()对文件进行内存映射,但随后底层文件更改为更小的大小。如果访问从文件中删除的内存偏移量,会发生什么情况?

IBM表示未定义http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fapis%2Fmmap.htm

如果映射文件的大小在mmap()之后减小,尝试引用超出文件末尾的是未定义的,并且可能导致MCH0601异常。

如果在mmap()函数完成后文件的大小增加,那么超出文件原始结尾的整个页面将无法通过映射访问。

在SingleUnixSpecification中也是如此:http://pubs.opengroup.org/onlinepubs/7908799/xsh/mmap.html

如果在调用mmap()之后,由于对映射文件进行了其他操作而导致映射文件的大小发生了变化,则对文件的添加或删除部分对应的映射区域部分的引用的影响是未指定的

'undefined'或'unspecified'表示允许操作系统开始格式化磁盘或任何东西。最可能的是sigsegv杀死你的应用程序。

这取决于你给mmap的标志,手册页:

MAP_SHARED共享此映射。对映射的更新可见映射此文件的其他进程,并将其执行到底层文件。文件可能直到msync(2)才真正更新。或者调用munmap()

MAP_PRIVATE创建一个私有的写时拷贝映射。更新映射对于映射同一文件的其他进程是不可见的,并且没有传递到基础文件。它是未指定的调用mmap()后对文件所做的更改是否可见映射区域。

所以对于MAP_PRIVATE,没关系,每个写入器实际上都有一个"私有"副本。(尽管只有在发生变异操作时才进行复制)。

我会认为,如果你使用MAP_SHARED,那么没有其他进程将被允许打开具有写特权的文件。但这只是猜测。

EDIT: ninjalj是正确的,文件可以被修改,即使你mmapMAP_SHARED

根据手册页,当您试图访问一个对于当前文件映射来说太大的地址时,mmap返回EINVAL错误。

"dnotify"answers"inotify"是当前Linux内核中的文件更改通知服务。据推测,它们将通知mmap子系统文件的更改。