2 questions about memory mapped files
in [Win32 Kernel]
|
From: Hector Santos on 12 Mar 2010 12:46 The only guarantee we have is an engineering one - we can only expect it it will behave that way. :-) Alexander Grigoriev wrote: > Does cache manager guarantee that the pages are flushed for a remote file, > when a logon session is being closed (an user logs out)? > > "Pavel Lebedinsky [MSFT]" <pavel(a)online.microsoft.com> wrote in message > news:%23K76VCbwKHA.4636(a)TK2MSFTNGP06.phx.gbl... >>> But in any case, the data is flushed when the file mapping object is >>> ultimately closed. >> There are two ways a modified mapped page can be written to disk: >> >> 1. As a result of an explicit FlushViewOfFile call. >> >> 2. After a page has been trimmed or unmapped from all working sets, >> the mapped page writer thread will (eventually) write it to disk. >> The OS makes no guarantees as to how long this will take, but >> eventally all such pages will be written to their backing storage, >> unless the system crashes or loses power, or the backing storage >> becomes unavailable (e.g. network is disconnected). >> >> Closing the file mapping object has no effect on when the pages will >> be written out. >> >> -- >> Pavel Lebedinsky/Windows Fundamentals Test >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> > > -- HLS
From: Pavel Lebedinsky [MSFT] on 13 Mar 2010 00:04 > Does cache manager guarantee that the pages are flushed for a remote file, > when a logon session is being closed (an user logs out)? Regular mapped files (as opposed to files mapped in the system cache) are managed by the memory manager alone. When a user logs off, the memory manager doesn't do anything special with regard to user mapped pages that have not been explicitly flushed, and doesn't provide any additional guarantees (besides what was already mentioned in this thread) as to when these pages will be written to their backing store. I don't think the cacher manager cares about user sessions either. Apps that want more control over when their changes are persisted should use FlushViewOfFile, FlushFileBuffers or non-cached IO. -- Pavel Lebedinsky/Windows Fundamentals Test This posting is provided "AS IS" with no warranties, and confers no rights.
From: Hugo gleaves on 17 Mar 2010 13:06 "gartaud" wrote: > Hello. > > I'm looking for definitive answers to those two questions: > > 1. When using a persisted memory mapped file, is there a guarantee made by > the OS that the content of the memory mapped file will always be written to > disk even if the application terminates unexpectedly? In other words, if we > write to a view but do not flush it and then the application crashes, are we > guaranteed that what was written to the view will make it to the file on disk? > > 2. When using a non-persisted memory mapped file backed by the system page > file for inter-process communication, is it possible to avoid that the > content of the memory mapped file be unnecessarily written to the system page > file? In other words, assuming there is enough physical memory on the system > so that paging out is not needed while using the memory mapped file, is it > possible to ask the OS not to write the content of the memory mapped file to > the system pagefile once were are done with it but simply discard it? > > Thanks! There are some very good answers already posted, so I'd print these off and keep them handy, fully understanding all this can take some effort and is not documented for clear reading! My answers are: 1. If app dies, exits cleanly or is killed then all modfied pages will be written to the disk file, this is true even if user logs off (even if an app dies and the OS begins to automatically flush, the logoff will be forced to hang until its done). You will get issues though if A) The OS crashes or B) The power is lost. 2. Yes. You can set some or all of the pages in the mapped region to be locked (non-paged) by calling VirtualLock. This will prevent the page (when modified) from ever being evicted. You can do this too for a file backed page, and in this case it will never be paged to the mapping file but will be flushed if you call FlushViewOfFile or the app dies, but not otherwise. So in my opinion doing a VirtualLock on a non-file based mapping will eliminate page faulting for that/those page/pages. Hugh
From: Jonathan de Boyne Pollard on 17 Mar 2010 16:29 > > > even if an app dies and the OS begins to automatically flush, the > logoff will be forced to hang until its done. > M. Lebedinsky has explained that that is a falsehood. WINLOGON doesn't do any magic at logout to flush dirty pages.
From: Hugo gleaves on 18 Mar 2010 10:44
"Jonathan de Boyne Pollard" wrote: > > > > > > even if an app dies and the OS begins to automatically flush, the > > logoff will be forced to hang until its done. > > > M. Lebedinsky has explained that that is a falsehood. WINLOGON doesn't > do any magic at logout to flush dirty pages. > > . > He didn't say that exactly. When you logout apps are stopped, forcibly if necesary. When any process terminates the system does flush all modified (dirty) mapped pages to the backing file. Now it may do this asynchronously, I am not sure, but it does do it. I just created a 1G mapped region, filled it with data (like 800 megs worth) using a test app that doesnt explicitly flush. When the apps finishes it just display a form and waits. I simply logged out and logged back in, the file was there and I ran a validation on its contents, it was fine, not a single updated page was missing. Hugh |