Have you ever lost power and lost data from a document you were editing? Has a server ever crashed in a datacenter, it's data corrupted, and now your company has lost a few 100k to a ffew million? Have you ever had to wait for processes to start again for a long time after fixing the hardware failure?
These are all problems that have been solved on EROS based system. They used to do demos where they would setup a system and have someone start working on some code or a text document, they'd pull out the power plug of the system, plug it back in and the user would be right were they left off. No data loss, no corruption, just back to work.
None of that was handled in user space. That was all opaque and you didn't have to worry about it at all.
How is that not slow as balls when you're hammering memory? Guaranteeing atomic writes to disk for every memory access would seem to be problematic from a performance perspective.
How is paging not slow as balls? When you're done changing your data, or your time quantum is up, you are paged and saved. The only difference now is if the system dies for some reason, you come back right where you were paged off.
So it's not right where you left off, and the program state is unknown?
I'm guessing the system must effectively "checkpoint" your work regularly and sync to disk to avoid partially saving a state and corrupting the data.
This isn't terribly different from working on a memory mapped file except that it also saves the ephemeral state of the running program so it can be restored. But I still don't understand how it's not going to be horribly slow when you start your program and the first thing it does is allocate 4GB of memory for its workspace. Synching all of that data to disk is a massive undertaking, and this isn't an uncommon use case, people start virtual machines all of the time.
And paging is slow as balls. That's what this whole article is about, modern machines are unusable when they start paging.
I've read somewhere that for BeOS demos they used to play a bunch of videos and music and then unplug/plug and after boot everything was playing again from where it left. I guess they were using the same design for process persistence.
That was just the media player remembering where it left off and restarting from that place. There may have been some metadata support in Be's filesystem to help that, but it's not technically necessary. It's about as amazing as your web browser reloading your tabs when you restart it.
It's a trivial problem if you're willing to run your system entirely off of the disk. I mean the performance will be unbearably slow, but you'll never lose your data.
These are all problems that have been solved on EROS based system. They used to do demos where they would setup a system and have someone start working on some code or a text document, they'd pull out the power plug of the system, plug it back in and the user would be right were they left off. No data loss, no corruption, just back to work.
None of that was handled in user space. That was all opaque and you didn't have to worry about it at all.