lkml.org 
[lkml]   [1999]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Some very thought-provoking ideas about OS architecture.
Date
From
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.115 / U:1.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site