Keep in mind that your whole linux system essentially mmaps your binaries / shared libraries when you run an application. And with caveats our world still keeps going around.

Error handling with mmap is a PITA but there's a few ways you can work around the general cases:

Use used mapped region for reading data and then use write() for writing it. That's what LMDB does. That's an assumption that's betting errors occurring in the write path.

If you're doing IO in a tight loop you can catch the SIGBUS sent to your thread (SIGBUS/SIGSEGV are always deliver to the thread that caused it). You can deal with the fault via sigsetjmp/siglongjmp. This has all sorts of fun draw backs (like if you're using C++ RAI after sigsetjmp).

Yes, and it does very admirable things there, brilliant things I would say. If you aren't going to touch the whole thing it doesn't have to load it from disk. If there is memory pressure it can just evict the in-memory copies of pages. All great stuff for that usage.

That said I have seen it cause issues. Most commonly I'd see it on Windows (it's not called mmap there, but whatever, same issue) if you run an app from a network share. Suddenly network timeouts make the whole app blow up. Not cool. There is actually a flag in the EXE file format that says "if you run this from a network, copy the contents to the pagefile first" - meant for exactly this scenario.