(Illustration by Gaich Muramatsu)
On Wed, Jan 01, 2003 at 06:47:04PM +1030, Brett Lymn wrote: > > This is probably related, possibly because coda is getting stuck in > the mount syscall but the output from df is wrong at this point too - > it only "comes good" when you use the coda file system (do a ls or cd > into it) only then does the output look right. Here is a sample: > Tracking things through it looks like this is related, I am guessing that the fields are not filled in by the initial mount because the tsleep was interrupted - I suppose they are filled in when the mountpoint is searched for... > > > So either we have to figure out why getNewVnode is called, or use the > > trick that is used for Linux and fork off a child process to perform the > > mount syscall. > > > > I will see if I can workout why getNewVnode is called. > OK - getNewVnode is NOT called during the venus start up. The function traceback is as follows: coda_call venus_statfs coda_nb_statfs sys_mount syscall_plain The statfs is done to fill in the data for the mount point. I think the problem is that in coda_call a wakeup is sent to the venus process to process a message, coda_call then tsleeps on a response from venus but in our case venus is waiting for the mount call to return so it will not process any messages (I am guessing this is so). This is why the linux approach works, the parent process is free to handle the messages for the mount whilst the child is blocked in the actual mount call. To me, forking a child to do the mount seems a bit hackish - coda_call should be able to detect the fact that coda is not mounted yet and avoid the deadlock. -- Brett LymnReceived on 2003-01-01 06:44:24