Coda File System

Re: Coda trial report & query

From: Peter J. Braam <braam_at_cs.cmu.edu>
Date: Mon, 22 Feb 1999 09:55:14 -0500 (EST)
Frank,

It looks like you didn't make a root volume on the server.  Did you see
the Coda howto? 

Also, I would VERY MUCH LIKE those Sparc patches I gave you since they
have apparently not been put in the source tree.  Can you mail them to me
please?

- Peter -


On Mon, 22 Feb 1999, Frank Bennett wrote:

> Dear Peter,
> 
> I wrote to you late last year about a plan to put Coda to use
> in our faculty here at Nagoya U.  I ran into difficulties with
> the stability of an external SCSI disk on a Sparc server we
> have here, and the project went on hold.
> 
> I have now determined that the SCSI problems had nothing to
> do with Coda.  The RedHat 5.2 Sparc Linux distribution uses,
> I am told, a patched 2.0.3x kernel which is compiled on egcs
> for the kernel, and gcc for some modules (including one or more
> of the SCSI modules).  The person who told me this suggested that
> 2.2.1 might be a better bet.  I've shifted the machine to the
> new kernel, and the SCSI problems went away.  Hurray!
> 
> I then compiled the 5.0.1 Coda server on the machine.  I had to make the
> change to the RVM start spec, as you suggested last year.  With that
> change, the 5.0.1 server comes up and appears to be stable.  It hasn't
> crashed in three days of quiet running. 
> 
> Today I pulled the Venus 5.0.2 RPM to my laptop, and tried to connect to
> the server.  After testing the connection to your test site (works like a
> charm), I shut down with vutil -shutdown, umounted /coda, and did: 
> 
>   venus-setup south-dacoda.nomolog.nagoya-u.ac.jp 20000
> 
> to point Venus at the local server.
> 
> When I restart Venus, it reports no errors to the console, but the logs
> show that it chokes.  It also evacuates from memory.  It leaves behind
> some clues in /var/log/messages.  Can you interpret these runes?  It looks
> like we need an SB, but I don't know what that is ... :-P
> 
> Since your server is accessible, there must be something wrong with our
> server here.  Possibly I need to set up an account of some sort at the
> server end? I've gone as far as installing the root volume; there's
> nothing below that.
> 
> The console report is:
> 
> *****
> 
> Date: Mon 02/22/99
> 
> 17:53:20 /usr/coda/LOG initialized at size 0x86f9c
> 17:53:20 /usr/coda/DATA initialized at size 0x21be70
> 17:53:21 brain-wiping recoverable store
> 17:53:21 loading recoverable store
> 17:53:22 starting VSGDB scan
> 17:53:22        0 vsg entries in table
> 17:53:22        0 vsg entries on free-list
> 17:53:23 starting VDB scan
> 17:53:23        1 vol entries in table (0 MLEs)
> 17:53:23        0 vol entries on free-list (0 MLEs)
> 17:53:23 starting FSDB scan (833, 20000) (25, 75, 4)
> 17:53:23        0 cache files in table (0 blocks)
> 17:53:24        833 cache files on free-list
> 17:53:25 starting HDB scan
> 17:53:25        0 hdb entries in table
> 17:53:25        0 hdb entries on free-list
> 17:53:25 Initial LRDB allocation
> 17:53:25 Venus starting...
> 
> *****
> 
> The following turns up in /usr/coda/etc/console:
> 
> *****
> 
> Feb 22 17:28:19 rm-325 kernel: Coda Kernel/Venus communications (module), v5.0-pre1, braam_at_cs.cmu.edu.
> Feb 22 17:28:33 rm-325 kernel: coda_psdev_write: downcall, no SB!
> Feb 22 17:28:52 rm-325 kernel: coda_read_super: rootfid is (0x7f000000,0x1,0x1)
> Feb 22 17:28:52 rm-325 kernel: Failure of coda_cnode_make for root: error -110
> Feb 22 17:31:17 rm-325 kernel: coda_psdev_write: downcall, no SB!
> Feb 22 17:33:36 rm-325 PAM_pwdb[751]: (su) session closed for user root
> Feb 22 17:33:44 rm-325 PAM_pwdb[957]: (su) session opened for user root by (uid=0)
> Feb 22 17:35:27 rm-325 kernel: coda_psdev_write: downcall, no SB!
> Feb 22 17:35:31 rm-325 kernel: coda_read_super: rootfid is (0x7f000000,0x1,0x1)
> Feb 22 17:35:47 rm-325 kernel: coda_downcall: opcode 30, no sb!
> Feb 22 17:35:47 rm-325 kernel: Failure of coda_cnode_make for root: error -110
> Feb 22 17:35:50 rm-325 PAM_pwdb[1005]: (su) session opened for user root by (uid=0)
> Feb 22 17:52:10 rm-325 kernel: coda_psdev_write: downcall, no SB!
> Feb 22 17:52:28 rm-325 kernel: coda_read_super: rootfid is (0x7f000000,0x1,0x1)
> Feb 22 17:52:28 rm-325 kernel: Failure of coda_cnode_make for root: error -110
> Feb 22 17:53:20 rm-325 kernel: coda_psdev_write: downcall, no SB!
> Feb 22 17:53:25 rm-325 kernel: coda_read_super: rootfid is (0x7f000000,0x1,0x1)
> Feb 22 17:53:40 rm-325 kernel: coda_downcall: opcode 30, no sb!
> Feb 22 17:53:41 rm-325 kernel: Failure of coda_cnode_make for root: error -110
> 
> *****
> 
> We also get the following in /vice/srv/SrvLog on the server machine. 
> SrvErr is empty.  Ignore the times (unless they're system critical!) ---
> looks like I haven't yet synced up the timeclock on that machine. 
> 
> *****
> 
> 08:15:55 Building callback conn.
> 08:28:13 Callback failed RPC2_DEAD (F) for ws 8506210e, port 2430
> 08:28:13 Unbinding RPC2 connection 132979470
> 08:28:13 Unbinding RPC2 connection 245885890
> 08:28:13 Unbinding RPC2 connection 988103743
> 08:51:20 Building callback conn.
> 08:53:43 SmonDaemon timer expired
> 08:53:43 Entered CheckRVMResStat
> 08:53:43 Starting SmonDaemon timer
> 09:06:43 Callback failed RPC2_DEAD (F) for ws 8506210e, port 2430
> 09:06:43 Unbinding RPC2 connection 707875326
> 09:06:43 Unbinding RPC2 connection 63410157
> 09:14:57 Building callback conn.
> 
> *****
> 
> Hope you can help (actually, I know you can help --- I have tremendous
> faith in you and your team, or I wouldn't have come along this far!),
> -- 
> -x80
> Frank G Bennett, Jr         @@
> Faculty of Law, Nagoya Univ () email: bennett_at_nomolog.nagoya-u.ac.jp
> Tel: +81[(0)52]789-2239     () WWW:   http://rumple.soas.ac.uk/~bennett/
> 
Received on 1999-02-22 09:59:16