D3 services requests for frames by the D3 Virtual Machine as follows. When the Virtual Machine requests a frame, the Monitor scans through all the frames currently in RAM to see if the requested frame already exists in a buffer. If it does, the Monitor hands the buffer over to the Virtual Machine. If it does not, a frame fault condition occurs. The Monitor goes to the disk, retrieves the frame, and places it in a buffer. It then releases the buffer over to the Virtual Machine for its use.
How is the buffer (frame) written back out to disk?
When the Virtual Machine releases a buffer, the Monitor has the option to write the buffer back out to disk at its leisure. Usually, this happens only when the Monitor needs the buffer for some other purpose such as another frame.
Which frame should the Monitor dispose of?
The Monitor employs a method of least recently used buffers to decide which ones to write out to disk. The newer the frame, the more likely it is to remain in RAM. The older the frame, the more likely it is demoted back to the disk. This scheme permits frequently used frames to stay in RAM due to the probability that they are needed again shortly.
The system RAM capacity determines the number of frames that can remain in RAM. The larger the system RAM, the greater the number of frames that can remain in RAM, requiring less frame shuffling and improving system performance. The more active processes running on the system, the more likely frames are requested that are not in RAM. All the buffers are flushed to disk before the system stops. The D3 flusher also is active at predetermined intervals, or whenever system activity lets up.
All of this means the information in RAM is different from the information on disk. The D3 file system is protected from corruption by mechanisms such as Halt Tolerance, transaction logging and transaction bracketing.