Memory Mapped File Handling

Memory mapped files in Chicago also need special handling by FSDs. A memory mapped file is basically an extension of the swap file. The memory mapped file now provides virtual memory for the system. This means that most of the restrictions that apply to the swap file also apply to memory mapped files. Thus, conditions (1), (3) and (4) listed in Swap File Handling for swap files apply directly to memory mapped files.

There are a few important differences, however:

1. Unlike condition (2), it is fine to cache data for memory mapped files. In fact, it would be preferable to cache them. While this may sound contradictory, there are a lot of memory mapped files that can get loaded again and again by different processes, in which case, it would make sense to cache the file even though it is eventually going to become memory mapped.
2. A memory mapped file cannot grow or shrink. Once a memory mapping is created to a file, the size of the mapping cannot change. It is conceivable that another process could open the same file and change its size, but this would cause an error during the memory mapping and, in itself, cannot affect system integrity.
3. A file is not opened memory mapped, instead, it is opened as a normal file and then a memory mapping is created for it. This means that the FSD now needs to transform the status of a file from normal to a special memory mapped file. For this purpose, the IFS manager calls the FSDs at the time the memory mapping is created so that the FSDs can now mark that this is a memory mapped file and lock everything down (if not already locked). The IFS signals this by calling the FSD on a zero-length read with a special flag R0_MM_READ_WRITE. This interface is described in section 8.5.23