2 questions about memory mapped files
gartaud
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!
Hector Santos
> 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?
No, you have to flush it. At least that has been our practice. For a
365x24x7 system, we make exclusive use of mapped files and if thye
customer's machine aborted or some idiot killed the process in some
automated maintenance thing and didn't follow our own automated
shutdown/restart procedure, they ended up calling support about file
integrity issues requiring them to run our repair tool.
In the last few years or so, we decided to minimize the support issues
and now flush every (record) write to avoid such issues. We watched
for complaints of performance. None, and thats probably because
machines and hard drives are much faster than the time our software
was first design many moons ago.
So you should measure it yourself for your needs.
> 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?
Can't answer that one definitively.
--
HLS
gartaud
-Gabriel
"Hector Santos" wrote:
> .
>
m
AFAIK, there is no way to dictate to the OS, besides FlushViewOfFile(), how
it manages the buffering of memory mapped files and the conditions under
which it will flush are OS version and configuration dependent. IMHO
memory mapped files are most useful for read-only data files and for
read-write or write-only, unbuffered overlapped IO is more easily
controlled.
"gartaud" <gar...@discussions.microsoft.com> wrote in message
news:5FD5F31A-0749-411E...@microsoft.com...
Alexander Grigoriev
"Hector Santos" <sant...@nospam.gmail.com> wrote in message
news:uXMrJtIw...@TK2MSFTNGP06.phx.gbl...
> gartaud wrote:
>
> No, you have to flush it. At least that has been our practice. For a
> 365x24x7 system, we make exclusive use of mapped files and if thye
> customer's machine aborted or some idiot killed the process in some
> automated maintenance thing and didn't follow our own automated
> shutdown/restart procedure, they ended up calling support about file
> integrity issues requiring them to run our repair tool.
>
> In the last few years or so, we decided to minimize the support issues and
> now flush every (record) write to avoid such issues. We watched for
> complaints of performance. None, and thats probably because machines and
> hard drives are much faster than the time our software was first design
> many moons ago.
>
I think you're mistaken. Whatever the application puts to the mapped memory
will be flushed to the file, even if the application dies. You problem was
more likely because an application killed in a wrong moment would leave
inconsistent state in the file.
gartaud
"Alexander Grigoriev" wrote:
> .
>
Hector Santos
killed, AG failed to take into account maps over the network.
Read the MSDN note on FlushViewOfFile() regarding its networking
notes, and thats if you do use it. If you don't, you have no clue
whether it is was flushed or not.
In fact, an option in our file mapping class allows a different
approach to FlushViewOfFile() - unmap the view, write to disk, flush
it, and then recreate the view. This is how we get better reliability
in a different customer environments where different storage
arrangements are possible.
We have enough field operations over thousands of installations to
know that different network driver provider can have different
networking caching than what you see on a local map. However, I will
note that over time, with OS and driver corrections, even speed, etc,
its rare to see the problems as we use to.
---
HLS
gartaud wrote:
--
HLS
Alexander Grigoriev
A mapped file is essentially just a cached file with its cache accessible to
the application. In fact, the file cache itself is implemented through the
file mapping. With that, the same guarantees apply to the file mapping, as
to a cached file.
Mapping a network file creates another failure point, which is unreliable
nature of network connections. If you lose connectivity, your data can't be
written back.
But in any case, the data is flushed when the file mapping object is
ultimately closed. How far flushed, depends on other attributes. For
example, if you open the handle without FILE_FLAG_NO_BUFFERING, the file may
also be picked by the cache manager, and then you may face undefined
write-back latency even after the file is closed.
"Hector Santos" <sant...@nospam.gmail.com> wrote in message
news:OGiGqhTw...@TK2MSFTNGP05.phx.gbl...
Pavel Lebedinsky [MSFT]
> 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.
Alexander Grigoriev
when a logon session is being closed (an user logs out)?
"Pavel Lebedinsky [MSFT]" <pa...@online.microsoft.com> wrote in message
news:%23K76VCb...@TK2MSFTNGP06.phx.gbl...
Hector Santos
it it will behave that way. :-)
Alexander Grigoriev wrote:
--
HLS
Pavel Lebedinsky [MSFT]
> 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.
gleaves@hotmail.com > <hugh<underbar>
"gartaud" wrote:
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
Jonathan de Boyne Pollard
>
>
> even if an app dies and the OS begins to automatically flush, the
>
M. Lebedinsky has explained that that is a falsehood. WINLOGON doesn't
do any magic at logout to flush dirty pages.
gleaves@hotmail.com > <hugh<underbar>
> .
>
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
gleaves@hotmail.com > <hugh<underbar>
"Pavel Lebedinsky [MSFT]" wrote:
> .
>
It is also worth stressing that one must ideally use FILE_FLAG_WRITE_THROUGH
and FILE_FLAG_NO_BUFFERING for the file handle used when creating the
mapping. It is my understanding that when one does this, the FlushViewOfFile
will only return to the caller AFTER ever single modified page has been
written to the physical disk drive.
Hugh
Alexander Grigoriev
"Hugo gle...@hotmail.com>" <hugh<underbar> wrote in message
news:7727D7E0-838D-4EE9...@microsoft.com...
Jonathan de Boyne Pollard
>>>
>>> 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.
>>
>
> [...] I simply logged out and logged back in, the file was there [...]
>
Now try attempting to demonstrate the forcible hang and flush of dirty
pages to disc that you claimed would occur, instead of something quite
different.
gleaves@hotmail.com > <hugh<underbar>
"Jonathan de Boyne Pollard" wrote:
> .
>
Jonathan the only circumstances I know of, that can lead to missing data
with memory mapped files and updates to them are:
1) OS crash
2) Power failure
3) Forced reset of machine
In all other cases you will not lose data, even if you logout/shutdown with
active processes that have unflushed mapped pages.
I have tested this with logout and shutdown, I just told you that and you
dismiss the test.
You claimed above that Mr Lebedinsky said that this was an untrue statement
"even if an app dies and the OS begins to automatically flush, the logoff
will be forced to hang until its done."
He did not say that, so why don't you go and reread his posts.
I'm not looking for a bickering contest Jonathan, the OP asked an important
question and it is important that we all try to stick with facts and not let
our ego intrude.
Hugh
Hector Santos
Hugo,
I think the point of all this is, IMTO, that you have need to be more
proactive to minimize the potential abnormal and/or ungraceful
shutdown event issues by:
- Add more explicit flushing logic.
- Implement automated WM_QUERYENDSESSION, WM_ENDSESSION
graceful exiting logic where necessary.
The OP asked a basic question:
"are we guaranteed that what was written to the view will
make it to the file on disk?"
The only guarantee anyone can have is one of expected design behavior.
But there is also a 2nd part of the question which adds a time factor
- an expectation it will be flushed at some future point in time.
IMTO, this introduces an engineering unknown that some MMF extensive
applications can't afford. One should not rely on waiting until the
OS and/or network drivers cache management to flush based on some
dirty page trigger point or until processes (graceful) exit.
While I agree ideally, lost of data is very minimal and today,
hardware, OS, networks, hard drivers are better, more reliable and
faster, in practice, it mandated a more direct control of the
situation to minimize the potential lost of data due to events outside
your control.
Finally, there was another factor why more explicit flushing helps-
the need to better support OFA (Open File Agent) and the introduction
of VSS for hot backups. For VSS, unless your process is VSS aware,
flushing helps with the integrity of the snapshots.
--
HLS
Jonathan de Boyne Pollard
>>>>>
>>>>>> 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.
>>>
>> Yes, xe did. Go and read all of what xe wrote.
>>
>>> [...] I simply logged out and logged back in, the file was there [...]
>>>
>> Now try attempting to demonstrate the forcible hang and flush of
>> dirty pages to disc that you claimed would occur, instead of
>> something quite different.
>>
>
For goodness' sake read! Read what you yourself claimed would happen,
that M. Lebedinsky had earlier explained to be a falsehood. And stop
repeatedly trying to prove something quite different.
> I'm not looking for a bickering contest Jonathan, the OP asked an
> important question and it is important that we all try to stick with
> facts and not let our ego intrude.
>
Then stick with them, and stop using ad hominems like this when it's
pointed out that some things are not facts but falsehoods.
gleaves@hotmail.com > <hugh<underbar>
"Jonathan de Boyne Pollard" wrote:
> .
>
OK I will correct one error I made earlier, and apologize if this caused a
misunderstanding. When I referred to "logoff" I should have written
"shutdown".
So to recap, if you have a single process, it creates a 1GB (for example)
mapping along with a new file for it. Then the process populates that data
block with some data, a Gigabyte - so that every mapped page has been
modified.
Then if you shutdown the machine, and this cause the app to be killed, ALL
THE DATA WILL BE AUTOMATICALLY WRITTEN TO DISK before the machines shuts off.
In the case of logging off, I was incorrect because in that scenario the
modified pages are asynchronously written to the file (eventually) by the OS
in its own time, shutdown of course forces the system to flush cached pages.
Now I am not and have not advocated "not flushing" I am aware and understand
the risks of relying on the machinery and OS in this way, and one should of
course always take steps to minimize the risk of data loss.
But that does not alter the fact that unless there is a powerfail, OS crash,
reset or hardware failure - memory mapped pages are always written to the
backing file at some point in time, usually failry quickly if apps die and
the file is no longer in use.
Now is this something you take issue with or can we at least agree on this?
Hugo
gleaves@hotmail.com > <hugh<underbar>
"Jonathan de Boyne Pollard" wrote:
> .
>
Finally read this sentence from a microsoft document about MMFs:
"Changes made to a memory-mapped file through a view of the file, other than
the system pagefile, are automatically written to disk when the view is
unmapped or when the file-mapping object is deleted."
This is taken from: http://msdn.microsoft.com/en-us/library/ms810613.aspx
I think you have to admit, that if one refers to officially published
material, then I am correct about this whole issue. Now if I am wrong (and I
may be) then we must accept that that official system documentation is wrong.
Hugh
Hector Santos
> Finally read this sentence from a microsoft document about MMFs:
>
> "Changes made to a memory-mapped file through a view of the file, other than
> the system pagefile, are automatically written to disk when the view is
> unmapped or when the file-mapping object is deleted."
>
> This is taken from: http://msdn.microsoft.com/en-us/library/ms810613.aspx
>
> I think you have to admit, that if one refers to officially published
> material, then I am correct about this whole issue. Now if I am wrong (and I
> may be) then we must accept that that official system documentation is wrong.
Right, but the above is insight into giving you the engineering
requirement to prepare for it. In other words, it told programmers
what will happen. The programmer now needs to prepare to unmap or
delete the file map object to get the system to auto-flush for you.
It doesn't mean that if a program ends (gracefully) without properly
unmapped and deleting the object that the system will do this for you.
Is it implied? I don't think so, I wouldn't trust it. You need to
close your handles properly.
Lets say your code is running and it has an file mapping object open,
and has not be flushed yet. If your process get a WM_QUERYENDSESSION
and/or don't handle a system broadcasted exit or shutdown event and
don't begin a cleanup phase, what happens to the unflushed data? Are
you sure objects that are not programmatically closed by your process,
the OS will be quaranteed to be flushed for you?
Can we simulate this with quick test?
- create a small console program with a file map
- add SMALL AMOUNTS OF data to the mapping view, no flushing.
- pause by calling _getch()
now abort the process by hitting control C.
See if the data was FLUSHED to the disk file.
I would also try this with a file across a network.
--
HLS
gleaves@hotmail.com > <hugh<underbar>
"Hector Santos" wrote:
> .
>
Well I've done such test many times, including forcibly killing the process,
delibertaley raising a fatal exception inside the process and shutting down
the machine when the process does no shutdown-handling.
In every case every page is correctly written to the disk.
When a process terminates (no matter how) the OS actually does the
terminating and executes an orderly sequence of cleanup steps, what we see as
a brutal crash in an app is not seen like that by the OS.
The OS must free up kernel space that has been used to store process and
thread descriptors, IO related kernel objects and many other things.
This involves automatically closing all handles opened by the app (handles
MUST be cleaned up, else other apps might think a file is in use etc) so in
short, unless the OS is prevented from operating (OS crash, powerfail etc)
then it doesn't matter what you do, die, crash, exit, close some handles, no
handles, all handles, unmap or not, all modified pages will be written to
disk.
Now I recognize that such modified pages, (when all sharers have exited)
will be written asynchronously and that this involves a degree of
uncertainty, so I never once advocated NOT doing a flush.
If you don't flush and the app dies, and then ten seconds later the OS
crashes, then yes, some modified pages may be lost I accept that. Doing a
flush reduces the size of this window, but then again the OS might crash 5
seconds before you do a flush!
So doing a flush is a very good idea (in most cases) and I have not said
otherwise, but the OP asks some very direct questions and I wanted to give my
view on this, I have used mapping and sharing a great deal in my career.
Hugh
Alexander Grigoriev
good as with CloseFile.
"Hector Santos" <sant...@nospam.gmail.com> wrote in message
news:O2xDD5dy...@TK2MSFTNGP02.phx.gbl...
Hector Santos
Alexander Grigoriev wrote:
--
HLS
gleaves@hotmail.com > <hugh<underbar>
will call CloseHandle etc for any process when it exits, so it is almost a
unimportant issue.
There is no way any OS would last very long if it required all apps to
behave strictly. Obviously one should close handles etc in non-trivial apps,
else one could (in say a big multithreaded network server) gradually consume
handles or something.
But there is no strict requirement for any app to explicity close handles.
The OS always cleans up internal resiurces used by any process, when that
process exits/dies.
To recap, one can only lose updates to file-backed mapped memory under these
situations:
1) Updates made, power fails.
2) Updates made, OS crashes (BSD or locks up)
3) Updates made, system gets a hardware reset.
4) Updates made, disk controller/disk drive fails.
5) Updates made, other serious hardware failure.
Other than that, updates cannot be "lost".
If its a single process and it dies/exits then all handles/views are closed
for you. The system will then write (asynchronously) all modified pages to
the disk medium at some time; if the system is shutdown then the cache
manager will immediately write all cached updates to disk.
If its a single process and it calls FlushViewOfFile then it will flush data
to the disk immediately (if file opened with WRITE_THROUGH then it will not
return from Flush until data has been sent to the disk drive itself).
If there are multiple sharing processes and one exits/dies then the system
will not asynchronously write updates to the disk (but updated pages might
get paged out by other system activity). When mapped pages are still in use
by other sharers the system leaves these pages alone. Only when all sharers
exit/die does the system then begin the asynchronous write.
The asynchronous writing is done by the cache mamager and it will do this
when there are modified pages in cache that are no longer in use (i.e. when
all handles from all processes are closed).
I have done tests with many gigs of mapped data, updated all that data then
have app sit in a wait. If I then do a shutdown, the shutdown is slow,
because it kills the app and then the cache manager is told "we're shutting
down, so please write all modified cached pages to disk before I switch off
box" and the cache manager does so, and it takes a while with several gig of
data, but it does it and you can see it takes far longer than a normal
shutdown and disk drive light is very busy.
This is what goes on inside, this is how it works, this is documented on web
and inside OS internals books from MS/Sysinternals people and device driver
books.
None of this recommends that we dont Flush, all this tells us is that
updated data wont be lost ever UNLESS a fault/crash occurs.
Of course killing apps/threads that use shared memory is a bad idea because
one can leave data partially updated or corrupted and one might even leave
locks held if on uses interlock functions for concurrency.
So there are sound principles to follow with mapping/sharing but the OP
questions were not about this aspect of the subject.
Hugo
"Hector Santos" wrote:
> .
>
Alexander Grigoriev
for the mapped file to flush properly. I said ExitProcess path is no worse
than your code.
"Hector Santos" <sant...@nospam.gmail.com> wrote in message
news:%232vT6Yk...@TK2MSFTNGP02.phx.gbl...
Hector Santos
application does is not listening to WM_QUERYENDSESSION?
Alexander Grigoriev wrote:
--
HLS
Alexander Grigoriev
applications would be screwed. That happens before the file systems are shot
down.
"Hector Santos" <sant...@nospam.gmail.com> wrote in message
news:uDuvyrqy...@TK2MSFTNGP06.phx.gbl...
Hector Santos
Alexander Grigoriev wrote:
--
HLS