Messages in this thread | | | Subject | Re: Some very thought-provoking ideas about OS architecture. | Date | Sun, 20 Jun 1999 11:54:54 +0100 (BST) | From | Alan Cox <> |
| |
> EROS is built around two fundamental and intertwined ideas. One is > that all data and code persistence is handled directly by the OS. > There is no file system. Yes, I said *no file system*. Instead, > everything is structures built in virtual memory and checkpointed out > to disk every so often (every five minutes in EROS). Want something? > Chase a pointer to it; EROS memory management does the rest.
This is actually an old idea. The problem that has never been solved well is recovery from errors. You lose 1% of your object store. How do you tidy up. 20% of your object store dies in a disk crash, how do you run an fscobject tool. You can do it, but you end up back with file system complexity and all the other fs stuff.
Another peril is that external interfaces don't always like replay of events. Consider for example a checkpoint restore of an object talking down a serial line to do money transfers
Please send $1 [CHECKPOINT] 0000 [CRASH] 0000 dollars to account 44515167
Getting this sort of stuff right requires a lot of care.
Another example (and an old real world one) about object persistence and the fact you can't checkpoint the universe:
At xx;00,xx:15,xx:30,xx:45 the cable pay per view box wakes up and checks if you have enough credit left, if so it deducts credit and goes back to sleep. If not it cuts off the film putting up a phone for more credit box
At xx:59:58 the user turns the box off for four seconds, at xx:14:58 the user turns the box off for four seconds...
You still end up with a lot of your objects having checkpoint/restart aware methods.
Moving just some objects between systems is fun too. You then get into cluster checkpointing, which is a field that requires you wear a pointy hat, have a beard and work for SGI or Digital.
> more hours and hours spent writing persistence/pickling/marshalling > code. The OS kernel is a lot simpler too; I can't find the figure to > be sure, but I believe EROS's is supposed to clock in at about 50K of code.
Their numbers are for a microkernelish core. They are still very good, but that includes basically no drivers, no network stack, no graphics and apparently no real checkpoint/restart in the face of corruption. I may be wrong on the last item.
> Here's another: All disk I/O is huge sequential BLTs done as part of > checkpoint operations. You can actually use close to 100% of your > controller's bandwidth, as opposed to the 30%-50% typical for > explicit-I/O operating systems that are doing seeks a lot of the time. > This means the maximum I/O throughput the OS can handle effectively > more than doubles. With simpler code. You could even afford the time > to verify each checkpoint write...
That nature of I/O is no different. If you always do large sequential block writes tell me how it will outperform a conventional OS if only a small number of changes in a small number of objects occur.
> Here's a third: Had a crash or power-out? On reboot, the system > simply picks up pointers to the last checkpointed state. Your OS, and > all your applications, are back in thirty seconds. No fscks, ever > again!
You can checkpoint Linux and suspend[1]. Right now it is a 'destructive' suspend in the sense that it pushes a lot of stuff out of memory but the mechanism is valid for checkpointing too. Doing it right requires a copy-on-write fs, just like the object store happens to require copy on write semantics for checkpointing.
[1] See 2.3.6ac1 which has the swsuspend patch in it, cleaned up a little
Object stores are great models for some applications, thats why libraries for doing persistent object stores in application space exist (eg texas)
Another way to look at this
File System Object Store
Index Inode Number Object ID Update Look in directory Look in an object Find item Find item location Write(maybe COW) Write(maybe COW) Page In Look in directory Look in an object Find item Find item location Write(maybe COW) Write(maybe COW) Granularity User controlled Enforced by OS
So if I promise to call my inodes object ids, call the directory structure "objects" and I have a checkpointing scheme - what is the great new concept.
> www.eros-os.org. Eric sez check it out. Mind-blowing stuff once > you've had a few days to digest it.
Some thoughts
o I don't think the object model is the good stuff
o The security model is very very interesting indeed.
o They are making it hard to help them however.
(quote from their mailing list) The EROS license requires that it be possible for me or my designates to do proprietary releases. If the drivers could be done outside the kernel this would not be an issue, but in this version of the system
Thats unfortunately going to make it harder to help them, both because a lot of people may find the idea that he's going to do closed versions of their work, and also because it makes it hard to share device drivers with their modified MPL licensed code until they have drivers running outside of kernel space (which is on their list)
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |