On Mon, Apr 23, 2001 at 05:21:23PM -0400, Andy Skunza wrote:
> Dear codalist,
> 
> Is it possible to mount a root filesystem via coda, instead of nfsroot,
> in a diskless workstation? My goal is thin client X terminals running
> their applications from one server.
> 
> Thanks for any help.

Coda cannot be used as a real root filesystem at kernel-boot time
because of the dependency on the userspace cachemanager (venus).

Venus also relies on having a regular filesystem as a persistent object
cache. This cachemanager cannot be started until 'userspace' is set up
and running, which requires the root-filesystem to be mounted first.
That said, it is possible to boot the kernel with an initrd, which can
set up the environment required to start venus.

Some problems, Coda still needs to store the cached files somewhere.
Currently these can only stored in an ext2 filesystem for which you
will really need a local disk. I've got some kernel patches, that
hopefully will make it into 2.4.4, which enable using ramfs as the
backing store. Some more tweaking would probably allow us to use tmpfs,
which is extremely useful when the 'diskless' box has a small local
disk that can be used for swapspace.

Also you probably don't want to store databases or logfiles in Coda.
Read-write access to databases from multiple clients pretty much
guarantees you to get nasty conflicts. Coda's whole file caching and
store-on-close semantics take all the fun out of logfiles. Either they
are only closed when rotated, i.e. server and other clients don't see
the data until the nightly logrotate script runs. Or logfiles are closed
and reopened after every written line, which gives a lot of data traffic.

So /tmp and /var should probably be stored on a local ramfs or tmpfs
filesystem. Also Coda-aware applications (cfs/repair/etc.) assume that
Coda is mounted as /coda.

My fs-root would either be the readonly initrd, or a ramfs/tmpfs
populated by extracting a compressed tarball from the initrd.

Coda is mounted as /coda, devfs mounted over /dev, usr and home are
links into /coda/{usr,home}. bin, lib, and sbin can be part of the
initrd they shouldn't really contain that many binaries anyways.
/tmp and /var link into a tmpfs mount (or mount 2 separate tmpfs
filesystems). Coda's cachefiles can be stored in /var/lib/coda/cache.

/etc is tricky, because some files are needed before Coda is running
(resolv.conf, hostname, coda/venus.conf) but most files are only needed
later on and should preferably be easily modifyable (i.e. stored in
/coda). Perhaps by selectively symlinking files from /etc/ to /coda/etc,
or storing /etc in the readwrite ramfs/tmpfs and populating it with
the less critical information once Coda is up and running.

Jan