On Thu, Jan 01, 2004 at 03:57:18PM +0000, Joerg Sommer wrote:
> begin  Jan Harkes <jaharkes_at_cs.cmu.edu> wrote:
> > On Wed, Dec 31, 2003 at 04:56:13PM +0000, Joerg Sommer wrote:
> > It is possible to kill venus and 'reattach' it without unmounting the
> > filesystem, but that isn't really documented (or recommended) anywhere.
> 
> While venus is detached, is it possible to open files?

No, as I said in my previous email, anything that requires a response
from venus will get EIO (or ENXIO). That is pretty much anything except
for read/write and previously successfull lookups that happen to be
cached by the kernel.

> > The problem is that we keep track of how many people have the file open
> > to avoid purging it from the cache while it is still being used, and to
> > only send the most recent version back (last writer closes). If you
> 
> That shouldn't be a big problem for me, because the hole volume is
> readonly.

It also applies to read-only opens, accounting is still screwed up and
venus could destroy/reuse a container file that is actively used, which
is fatal for the application. And even when it doesn't reuse the
container file, it will still die as soon as it receives the unexpected
close upcall.

> >> What's the reason for this? Currently, we're running a computer pool with
> >> diskless clients based on AFS. But AFS has the know disatvantages and we
> >
> > If the clients are truly diskless, where is the local cache (and RVM)
> > stored? I know, silly question. But technically a truly diskless client
> 
> On a ramdisk.

Ok, in that case you don't have persistency across reboots. If you don't
care about persistency across venus restarts you could use the -rvmt 3
flag and effectively reduce memory usage. Right now the metadata is
stored,

 - in the RVM data file
    this is normally the persistent store and it is loaded whenever
    venus is restarted.

 - in RVM log
    pending updates waiting to be applied to the RVM data file.

 - in VM (main memory/swap)
    we use a private mmap or simply allocate as much memory as RVM data,
    so any modified data will not be backed by the RVM data file (for
    consistency reasons) and will end up in swap.

Because you don't have persistency, all RVM will be 'dirty', and since
you use a ramdisk the metadata ends up being stored in memory in all
three locations.

With the -rvmt 3 flag (RvmType == VM) we avoid using RVM log and data,
but simply use malloc instead of rvm_malloc to get the place to store
our metadata. The rvm transactions are no-ops because there clearly is
no persistent store that can survive a venus restart.

> Now, we boot an initrd and load there openafs module and start afsd. With
> coda we plan to boot an initrd, start venus from there (maybe an older
> version), fetch venus from the server and restart this up to date
> version.

Why not have the up to date version in the initrd in the first place?
Or fetch a current venus with wget from the initrd, wget is much smaller
than venus and you should already have a network anyways. It is simply
not possible to reliably restart venus on a system that is already
actively using Coda.

Jan