(Illustration by Gaich Muramatsu)
On Wed, Nov 09, 2005 at 03:49:51PM -0500, Chong Sein Yeo wrote: > Hello Guys, > I am experiencing some difficulty and was wondering if anyone have any clue > on what may be happening. > > I ran > "venus-setup host1.mydomain.net <http://host1.mydomain.net>, > host2.mydomain.net <http://host2.mydomain.net> 200000" ??? That's some weird arguments for venus setup. It really only takes 2 arguments, - the realm name, which is only used by clog/cunlog/cpasswd - the desired cache size Venus doesn't ever use the realm name, it is mostly a convenience thing for the user so that he doesn't have to type, clog codausername_at_my.local.coda.realm.name That @my.local.realm.name part defaults to the realmname= value in /etc/coda/venus.conf, which was set by venus-setup. So if that is set to something it is possible to simply type clog codausername The codausername part defaults to the login name of the user who invoked the clog command, so if the Coda usernames match the usernames on the local system it is even simpler and the user simply types, clog > 14:00:30 starting FSDB scan (8333, 200000) (25, 75, 4) Interesting, it looks like venus did pick up the right cache size. > 14:00:30 /coda now mounted. > ***LWP (0x8116e38): Select returns error: 4 > > I was just wondering if anyone have any clue on why I am getting that LWP > Error? Also, i am running Coda version 6.0.14 LWP version 2.1 That error is harmless (EINTR). What happens is that when we try to mount /coda, the kernel has to ask the venus process what the attributes of the top level directory are so that it can create the inode object of the root. But mount is a blocking system call, which would mean that a single thread would get stuck in the mount, since venus is unable to handle upcalls while it is blocked waiting for the mount to complete. Because we don't expect all platforms to have threading, in fact most of Coda was written before pthreads was even a standard, we fork of a child process which does the mount("/coda"). The main process can then handle the upcalls needed to complete the mount process. When the mount completes the child exits and sends a signal to the parent. The parent is waiting in select for new upcall messages from the kernel which gets interrupted, ergo the EINTR error. Because the mount completed, Coda should be up and running at this point. You could see if 'ls /coda/testserver.coda.cs.cmu.edu' works. JanReceived on 2005-11-09 16:33:40