I'm evaluating a technique to implement a sort of an event logger that uses MAP_SHARED mapping of a file in the app sandbox as an event ring buffer. The reason to use mapping instead of traditionally allocated memory is to achieve log persistence across app termination of any kind (crashes, sigkill, etc.) and keep logs fast by avoiding syscalls. By definition MAP_SHARED area must be coherent with any other RW operations in the system on that file slice which practically means that kernel has to use page cache that is used to serve RW requests. This in turn means that after app process terminates by any reason - content of that memory will not be discarded but rather will be available on next app start via open()/read() or mmap() for that file. msync() can be used to tell kernel to initiate "writeback" - to flush modified mapping pages to the corresponding locations in the non-volatile storage but I haven't found any description of what is the writeback policy if user opts to NOT use msync() at all. And similarly no means to control this. In my case it appears to be important as if kernel does some automatic writebacks on its own - intensive logger traffic would put unneeded IO load to a disk device. After some experiments I was able to figure out that e.g. Linux is able to issue periodical writebacks w/o explicit msync(). For OS X according to "fs_usage -f diskio" no writeback occurs until app terminates (better to say until last reference in the system to that MAP_SHARED area is dropped). I'm now interested to learn about iOS behavior. Is it the same as OS X (no automatic writebacks)? Alternatively I'd happy to hear if there are other techniques available for iOS app to "pin" some memory so its content could survive app termination. Shared memory with an associated "retainer" process would work on other platforms but here we are limited to a single process. Thanks.