From owner-freebsd-fs@FreeBSD.ORG Wed Feb 13 11:12:13 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 6390016A41B for ; Wed, 13 Feb 2008 11:12:13 +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 40C6513C4E5 for ; Wed, 13 Feb 2008 11:12:13 +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 C03A546BBC; Wed, 13 Feb 2008 06:12:12 -0500 (EST) Date: Wed, 13 Feb 2008 11:12:12 +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: <20080213105632.A13849@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 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: Wed, 13 Feb 2008 11:12:13 -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. > >> - 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. I explored this issue a bit more, and have some local patches to make Coda on FreeBSD use the global VFS namecache, which seems to help with some of these problems. However, there is one case it's not helping with: stat("..", &sb) on the root of /coda/testserver.coda.cs.cmu.edu returns ENOENT once the namecache is flushed as a result of a CODA_PURGEUSER (i.e., cunlog). It looks like Venus is returning a lookup error: cinnamon-coda# clog guest username: guest@testserver.coda.cs.cmu.edu Password: cinnamon-coda# cd /coda/testserver.coda.cs.cmu.edu/ cinnamon-coda# cul cinnamon-coda# cunlog cinnamon-coda# stat .. stat: ..: stat: No such file or directory Here's the kernel module debug output: Doing a call for 9.663 vcwrite got a call for 9.663 lookup: .. in [2.7f000000.1.1] Doing a call for 10.664 vcwrite got a call for 10.664 lookup error on [2.7f000000.1.1] (..)2 So it looks like venus_lookup() isn't returning /coda's fid on a lookup of ".." in /coda/testserver.coda.cs.cmu.edu. The BSD Coda kernel module (and presumably the original Mach code it was based on) has a credential-tagged namecache, so actually flushes the namecache for the uid passed into CODA_PURGEUSER. Linux's Coda module has an access cache that it flushes for all users on CODA_PURGEUSER, but doesn't touch the namecache. I can adopt the same approach in FreeBSD, but I think venus probably should know how to resolve ".." for the kernel module, rather than relying solely on the namecache. Robert N M Watson Computer Laboratory University of Cambridge