From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 06:26:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C431416A4CF; Mon, 4 Oct 2004 06:26:19 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E31443D41; Mon, 4 Oct 2004 06:26:19 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <4160ED06.6070603@geminix.org> Date: Mon, 04 Oct 2004 08:26:14 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041002 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takanori Watanabe References: <200410040606.i9466UVm012207@sana.init-main.com> In-Reply-To: <200410040606.i9466UVm012207@sana.init-main.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1CEMIa-000NRR-00; Mon, 04 Oct 2004 08:26:17 +0200 X-Mailman-Approved-At: Mon, 04 Oct 2004 12:02:39 +0000 cc: freebsd-fs@FreeBSD.org cc: Boris Popov cc: das@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 06:26:20 -0000 Takanori Watanabe wrote: > In message <20041004053106.GQ88303@vertex.kz>, Boris Popov wrote: > >>On Sun, Oct 03, 2004 at 11:06:42PM +0200, Uwe Doering wrote: >> >>>>That isn't the issue. The issue is that an application might open >>>>the vnode in the unionfs mount, and another application might >>>>modify the same file in the underlying file system. If the kernel >>>>doesn't understand that it is really the same file, then cache >>>>incoherencies will occur. I'm actually not sure to what extent >>>>this is a problem already; John Heidemann's Phd thesis had a way >>>>of dealing with it, but FreeBSD doesn't do things that way AFAIK. >>> >>>Okay, but that's a different matter. What I was addressing at the start >>>of this discussion is an ambiguity issue with meta data, that is, >>>information that ends up in stat(2) and friends. >> >> Exactly, one never knows what parts of metadata used by applications. >>I can confirm that ino are ought to be unique inside filesystem, otherwise >>some programs will fail in a very obscure ways. > > Ok, the issue Uwe says is when underlying filesystem and > wrapping filesystem are diffent and if there are two files > with same identifier exists. > And the issue I want to fix is when underlying filesystem and > wrapping filesystem are same so getcwd routine failed to distinguish > the mount point. > > So it can be solved by translating fsid if the fsid of a file is same as > that of mountpoint. True? Correct. In this case the inode number is guaranteed to be unique. This might be okay as a local patch, but it is IMHO not a fix suited for FreeBSD in general. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net