19

This may have a different answer between OSX, Windows and Linux.

If the process crashes, will dirtied pages from the mmap be discarded or written out eventually by the OS, assuming it does not crash?

It's clear that they persist if another process has mapped them, but what if the crashed process was the only one? I'm interested both in what is technically promised in docs and what the implementation actually does. If you only know for one OS please respond for just that one.

Eloff
  • 20,828
  • 17
  • 83
  • 112
  • 1
    Related: http://stackoverflow.com/a/6219962/489590 – Brian Cain Aug 07 '14 at 00:32
  • 1
    As long as OS itself doesn't crash, it should be reclaimed because the kernel definitely tracks the locations and size of all the segments that a process uses, regardless it exits normally or is killed by a signal, etc. – Eric Z Aug 07 '14 at 00:35
  • @EricZ yes, it will definitely be reclaimed, but my question is what happens to the dirty pages backed by a file? Will they be written to the file, discarded, or undefined? – Eloff Aug 07 '14 at 00:42
  • 1
    @Eloff, OS should have a chance to commit dirty pages before reclaiming RAM even in case of a process crash. I suggest you write some code to verify it by setting a long enough commit interval and crash your process in between. – Eric Z Aug 07 '14 at 00:52
  • 2
    @EricZ - I suspect he would like to know if someone has an *answer*, backed by documentation. Such a test might return false-positives anyway, even if the OS doesn't provide a guarantee. – Brett Hale Aug 07 '14 at 01:16
  • After a couple more hours of research I found code samples and reports that the system does indeed eventually flush the pages to disk for Linux and Windows. And it makes sense because to do otherwise adds a whole extra case to the kernel logic that wouldn't otherwise be needed. – Eloff Aug 07 '14 at 01:52
  • @Eloff That's cool! Maybe you can put it as an answer so that others can vote. – Eric Z Aug 07 '14 at 02:49
  • The link from @BrianCain gives pretty strong evidence, including program code for Linux that it will eventually write the dirty pages out. – Eloff Aug 07 '14 at 04:48

1 Answers1

2

For Windows, I don't think there is any doubt that dirty pages are eventually written to disk. It is explictly documented that unmapping a file view does not flush the data, but the data will be written lazily to disk as with any cache. FlushViewOfFile forces an immediate write, but calling it is optional.

There are exceptions which may or many not be relevant. Two mapped views of a file are guaranteed to remain coherent even if one program terminates abnormally, but this coherency does not extend to remote files or to files accessed concurrently using ReadFile/WriteFile.

The documentation does not provide an explicit answer, but neither does it give any hint that the opposite might be true. I would rely on, subject to testing.

And as pointed out in a link, if there is a risk of machine failure it might be a good idea to make sure the pages get flushed as they are written. Kernel flushing the cache could be delayed quite a while.

david.pfx
  • 10,520
  • 3
  • 30
  • 63
  • 1
    I found this discussion (and test results) which seems to confirm that for windows: https://groups.google.com/forum/m/#!topic/microsoft.public.win32.programmer.kernel/_PvdXW2xSEU – Eloff Aug 07 '14 at 04:42
  • 1
    Also this gives good rationale for why the kernel would write out dirty pages: http://blogs.msdn.com/b/oldnewthing/archive/2010/04/28/10003540.aspx – Eloff Aug 07 '14 at 04:52
  • @Eloff: The msdn link exactly mirrors my thought processes (but more elegantly). The google groups link is less helpful, and would seem to blend into cases where the whole system crashes before flushing the cache. – david.pfx Aug 07 '14 at 04:56