[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.
    > 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
    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

    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.

    > 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)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.026 / U:0.452 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site