Re: RE : Re: [tlug] Small footprint Linux distribution without a GUI

["Stephen J. Turnbull" <stephen@example.com>]

Jedidiah Israel writes:

 > Correct. But don't you think with the union filesystem hurdle
 > accomplished, that it is a matter of time before it is extended across
 > the network? :)

Export it via NFS.  Done deal. ;-)

But no, I don't think it is a matter of time.  There are almost
certainly major design decisions to be made, and each alternative is
probably valuable and therefore will require Yet Another
Implementation.

The Coda distributed file system is a good example here.  Coda *is* in
a sense a distributed union file system.  There is a local cache file
system (not yet cachefs, but Jan Harkes has expressed interest in
going in that direction), which is intended to be *all* of the files
that the user uses.  However, caches are finite and new files do every
so often appear asynchronously, so if there's a cache miss, the client
file system goes out and retrieves the missing file from the network
file system.

Now, here's the catch.  Unix[1] file semantics assume that opening a
file is atomic and instantaneous.  But obviously even with gigabit
networks, a multi-gigabyte file cannot be opened both instantaneously
and atomically.  Coda chooses to give up on instantaneous; open blocks
until *all* of the file is in cache.  It feels like weeks waiting for
a DVD image to open. :-)  NFS makes a subtle compromise, but to a good
approximation, NFS punts on atomic (what if the network stalls or goes
down just before you do a fseek (fp, 0, SEEK_END)?)

The Coda list is full of people in pain because their application
cannot stand up under NFS semantics, but their users refuse to "gaman"
through Coda semantics.  (They typically propose to reinvent NFS
semantics, but "somehow" make them atomic like Coda.)

 > It took around 10,000 mistakes before the light bulb was invented. :)

That's OK in hardware, where the developer bears the cost.  It is not
applicable to open source software, because it's the beta testers who do.

Footnotes: 
[1]  I don't think that's true of the POSIX standard; I write "Unix"
because this is the way Unix users and application developers think.