Various FreeBSD Coda fixes

[Robert Watson]

On Mon, 21 Jan 2008, Jan Harkes wrote:

>> - ".." and "." sometimes appear to have problems in the root directory of the
>>   root volume of a realm (i.e., /coda/testserver.coda.cs.cmu.edu).  I'm not
>>   sure if this is a Coda client bug or a kernel bug, quite possibly the
>>   latter.  This most likely won't be fixed for 7.0 unless it jumps out at me
>>   tomorrow.
>
> Known Coda client problem. Across the volume mount we have 2 different 
> objects, the root of the volume and the mountlink object on which is it 
> mounted. If you do a low-level readdir on the parent you see the identifier 
> of the mountlink and not the volume root. So stat('.') in the volume root 
> cannot be found in the readdir('..') information, the only way to match it 
> up right now is to stat() every entry you got back from readdir.

Well, there are two problems -- one is the lack of matching inode numbers 
causing problems for getcwd(), the other is that sometimes stat("..") fails 
with ENOENT in /coda/testserver.coda.cs.cmu.edu.  I was assuming that was a 
namecache or related bug in the FreeBSD version of the module, and should take 
a look and see if something similar was fixed in NetBSD.

>> - getpwd() appears to have problems, possibly related to the previous bug 
>> if
>>   it's unable to recurse to the root.  Because Coda doesn't use the global
>
> Correct. I really see this as a Coda client issue, although is has been 
> fixed in the Linux kernel module by peeking in the in-kernel directory 
> cache. Effectively similar to calling stat(2) on all children as long as 
> they are cached, and the components of the path we're looking up are 
> guaranteed to be cached because they are held pinned down by the cwd 
> reference of the process that calls getcwd.

It used to be the case that the "inode number" exposed by Coda was a hash of 
the viceid, which reduced 96 bits (now more) to 32 bits, leading to two 
problems: (a) that if a vnode spanned two volumes, it had two viceid's 
representing the historic "mounted on" and "mounted over", and (b) the 
possibility of colliding inode numbers.  Maintaining a database of viceids to 
inode numbers is undesirable both because of the size and general feasibility 
of such a database, but have you thought about maintaining a special database 
of mapped inode numbers for just the volume grafting points?  There are quite 
a lot fewer of them running around so they could perhaps be generated and used 
specifically.

Robert N M Watson
Computer Laboratory
University of Cambridge