(Illustration by Gaich Muramatsu)
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. JanReceived on 2004-01-03 00:49:44