Re: Various FreeBSD Coda fixes

On Sat, 19 Jan 2008, Robert Watson wrote:

> I'm not sure if these can be MFC'd before 7.0, but will
ask re if we can 
> fit them in.  Certainly, it's better than panicking,
which is a relatively 
> likely scenario with what's currently in RELENG_7.

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'm aware of four outstanding problems:

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

- Linux binaries have problems listing directories in Coda
under Linux
   emulation.  Won't be fixed for 7.0.

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

- 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
   VFS namecache, the __getcwd() system call which is often
able to resolve the
   current directly doesn't work with Coda; the userspace
implementation walks
   to the root looking for the child directory in each
parent, which can have
   problems if stat() and inode numbers are inconsistent, or
if there's a
   broken ".." step.  Ditto on this most likely
not being fixed for 7.0.

Any other problems, especially panics with the backport of
the other fixes to 
RELENG_7, are very much fair game, but having the reports by
the end of 
Tuesday would be extremely helpful.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"

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
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"