[OpenAFS] strange error in directory / volume

Rubino Geiß kb44@rz.uni-karlsruhe.de
Tue, 3 Dec 2002 09:32:32 +0100


> On Mon, 2 Dec 2002, Derrick J Brashear wrote:
> 
> > i assume you can't boil it down into a simpler test case than using 
> > GConf?
> > 
> > if not, i suggest:
> > -use a recent tcpdump and watch the network to see exactly what 
> > operations are sent (tcpdump -vv -s 1500 port 7000 and host 
> yourhost  
> > should be sufficient) -make sure fstrace is configured usefully 
> > (afszcm.cat installed in  /usr/vice/etc/C or wherever 
> you've compiled 
> > afs to expect it) -enable fstrace on the client (fstrace setset cm 
> > -active) , make the  problem happen, fstrace dump cm > somefile
> > -send the packet trace and the fstrace dump to 
> openafs-bugs@openafs.org

I already solved the problem on all volumes. I do not exaclty know how
to reporduce it. So I cant provide it either... Maybe I should log on
form different clients via a genome session to trigger the bug?

I also proviede som salv-logs dont they contain useful information for
experts?

> FWIW, this exact same thing happened to me.  I can't provide 
> any of the 
> above info because I didn't spend much time on this since I'm 
> (so far) the 
> only person at our entire university to ever complain about 
> this.  I think 
> this happens when you run 2 gconf aware apps simultaneously from 2 
> different machines.
> 
> An obvious problem here is that gconfd relies on 2 things 
> that AFS doesn't 
> fully support:  file locking and hardlinks.

Does anyone know any specific details?

> If you throw together a quick C or perl program that calls opendir() &
> readdir() you'll see that the directory entry for "ior" 
> exists but if you try to stat() it, you'll get ENOENT.  I 
> have no clue what could cause this 
> to happen.
> 
> I fixed my broken directory by running bos salvage on my 
> volume and I stopped running gnome on 2 different machines 
> simultaneously when they both look at the same homedir.

Maybe this is a temporary solution, but ... somewhat subobtimal.

> Dave

Bye, Ruby