Date: Tue, 22 Jan 2008 09:34:21 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Jan Harkes <jaharkes@cs.cmu.edu> Cc: fs@FreeBSD.org, Rune <u+openafsdev-sr55@chalmers.se> Subject: Re: Various FreeBSD Coda fixes Message-ID: <20080122092743.J58270@fledge.watson.org> In-Reply-To: <20080122040252.GI30266@cs.cmu.edu> References: <20080119165056.E3375@fledge.watson.org> <20080122010003.B29737@fledge.watson.org> <20080122040252.GI30266@cs.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080122092743.J58270>