Memory Mapped Files

Having studied the requirements of the users towards managing the files we take a small detour in this chapter to introduce ourselves to a concept called the memory mapped files.

If you're acquainted with the concept of memory mapped I/O this concept is easy to understand. It was found that programmers prefer to read/write on the system memory than to operate on files that are on the external I/O realm. Which is quite justifiable for the simplicity and time effeciency memory read/write offers as against the I/O read/write.

Many operating systems have provided a way to map files into the address space of a running process. Conecptually, we can imagine existence of two system calls, map and unmap. Used to map files into the virtual address space, and unmap them when done processing.

For example, suppose that a file, f, of the length 64 KB, is mapped into the virtual address starting at address 512K. Then any machine instruction that reads the contents of the byte at 512k byte 0 of the file, and so on. Similarly, a write to address 512k + 21000 modifies byte 21000 of the file. When the process terminates file is left on the disk, just as though it had been changes by a combination of seek and write system calls.

What actually happens is that the system's internal tables are changed to make the file become the backing store for the memory region between 512k to 576k. Thus a read from 512k causes a page fault, bringing in page 0 of the file. Similarly, a write to 512k + 1100 causes a page fault, bringing in the page containing that address, after which the write to memory can take place. If that page is evicted by page replacement algorithm, it is written back to the appropriate place in the file. When the process finishes, all mapped, modified pages are written back to their files.

File mapping works the best in a system supporting segmentation. In such a system, each file can be mapped into its own segment and mapped into the virtual address space of the running process so that, byte k in the file corresponds to byte k of the segment. Suppose that a process has to copy contents of a certain file abc to another xyz. The process had two segments, program text and data. The process will map file abc into a particular segment and then creates another segment xyz. Now we need only to copy contents from segment to anothe through a simple copy loop. No need of read write I/O system calls to be made. When it is all done, we can execute the unmap system call and remove the file the address space and exit. The output file xyz is now assured to be present.

Now. The limitations of using memory map for files.

1. From our example, it is hard to know the exact size of the target file in terms of numbet of bytes. Since the unit of data being copied is a page and we could tell only the precise number of pages written. Suppose that the program only uses page 0 and after execution all the bytes are zeroes. We do not know for sure if the number of zeroes actually to be present are 10, 100 or 500.
2. A second problem can occur if a file opened in by one process and opened for conventional reading by another. If the first process modifies a page, that change will not be reflected in the file on disk until the page is evicted. The system has to take great care to make sure the two processes do not see inconsistent versions of file.
3. A third problem is that the file may be larger than a segment, or even larger than entire virtual address space. The only way out is to arrange the map system call to be able to map a portion of a file, rather than a entire file at once. Although this works, it is clearly less satisfactory than mapping the entire file.