From owner-freebsd-fs@FreeBSD.ORG Tue Jan 22 09:34:22 2008 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74D3916A473 for ; Tue, 22 Jan 2008 09:34:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 304BD13C4E1 for ; Tue, 22 Jan 2008 09:34:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id DA3934A5D3; Tue, 22 Jan 2008 04:34:21 -0500 (EST) Date: Tue, 22 Jan 2008 09:34:21 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jan Harkes In-Reply-To: <20080122040252.GI30266@cs.cmu.edu> Message-ID: <20080122092743.J58270@fledge.watson.org> References: <20080119165056.E3375@fledge.watson.org> <20080122010003.B29737@fledge.watson.org> <20080122040252.GI30266@cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: fs@FreeBSD.org, Rune Subject: Re: Various FreeBSD Coda fixes X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2008 09:34:22 -0000 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