Various FreeBSD Coda fixes

[Jan Harkes]

On Tue, Jan 22, 2008 at 01:04:31AM +0000, Robert Watson wrote:
> I've merged these, and a couple more since then, to RLEENG_7, and will 
> request an MFC to RELENG_7_0 to include them in the forthcoming FreeBSD 
> 7.0.  It would be very helpful, if you have a 7.x box, if you could 
> update to the head of RELENG_7 to pick up these fixes, and test with Coda 
> with them.

I will upgrade my vm and test.

> - Rune has reported a hang with X11 and Coda, but we haven't yet been able to
>   track it down much yet -- might not be related to Coda.

He does tend to run pretty much everything out of Coda, and is very good
at triggering bugs which can be very hard to reproduce in isolation.
Wouldn't surprise me if this is somehow a Coda bug he manages to trigger.

> - ".." 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.

> - 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.

Jan