That depends on if you want to consistency check your object store after a
crash. Unless you journal the object store - which btw is hard. If you have
two thousand inter-related objects you need to dump the set of them
consistently and in a snapshotted state.
Funnily enough "object system" and file system journalling are identical.
> is run its own debugging and benchmarking tools. Still, the fact that
> the test kernel can be that small is IMO an argument that the design
> is sound.
V7 Unix is smaller than that. System III is about 60K on a 68010 CPU.
> > 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.
>
> No seeks to read inodes, because the map from EROS's virtual-space
> blocks to disk blocks is almost trivial (essentially the disks get
> treated like a honkin' big series of swap volumes). So the disk
> access pattern would be quite different, I think.
Not really. The mapping of objects to disks is complex the moment you allow
an object to expand or want to reclaim space. Again it is the same problems
1. You need an indexing object - in a fileystem it is a directory or
directory tree
2. You need to position objects/files for locality
3. You need fragmentation resistant algorithms
There are arguments about how you provide this - ranging from conventional
cylinder groups through log structured file systems to stuff like reiserfs
where the fs is viewed much more in a database fashion.
It doesn't matter if your email is an object or a file or a database record,
they are the same thing. Your handle just changes name.
> That, under most circumstances, you don't have to manage persistence
> yourself (or to put it more concretely, no explicit disk I/O in most
> applications). That's clearly a huge win, even if you end up having to do
> more conventional-looking things in applications that require
> commit/rollback.
Why is having persistence managed by a library that is playing guessing games
of your intent a good idea ? It has to know about object relationships,
potentially it has to blindly snapshot the entire system. It has to do a lot
of work to know in detail what has changed.
Again this is identical to conventional file system problems. if you've ever
tried to send someone a file not knowing what other files it happens to include
or need, you've met the object relationship problems.
So all you have to do is export every object that this object refers to. Like
the windowing environment, whoops oh dear. I've worked with persistant object
stores of sorts. AberMUD5 is a multiuser game that is basically a persistant
object store. The "how do I split something off from the rest" problem isn't
fun. You can do most of it by making a logical copy of the object store
marking the objects you want as needed and garbage collecting the rest. However
even if you then are smart about some of the object linkages you still find
large numbers of objects that wont go away and whose connectivity and relation
to the stuff you want is very complex even to visualise.
> What I'm thinking is this: remember RT-Linux? Suppose the kernel were
> a process running over an EROS-like layer...
Suppose Eros was just a set of persistent object libraries that ran on
top of numerous other platforms too, could be downloaded off the net and worked
pretty well within the limits of the "programmer lazy, do more work than
needed" paradigm.
ftp://ftp.cs.utexas.edu/pub/garbage/texas/README
And that is demonstrably the right way up. If you put a "lazy programmer"
system at the bottom of an environment you prevent the smart programmer doing
smart things. If your bottom layer is fundamentally ignorant of programmer
provided clues you cripple the smart.
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/