From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 06:18:20 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 267FE16A4CE; Mon, 4 Oct 2004 06:18:20 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA6D143D1D; Mon, 4 Oct 2004 06:18:19 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i946IToh011539; Mon, 4 Oct 2004 02:18:29 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i946ITp7011538; Mon, 4 Oct 2004 02:18:29 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 4 Oct 2004 02:18:29 -0400 From: David Schultz To: Takanori Watanabe Message-ID: <20041004061829.GB11422@VARK.MIT.EDU> Mail-Followup-To: Takanori Watanabe , Boris Popov , gemini@geminix.org, freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <20041004053106.GQ88303@vertex.kz> <200410040606.i9466UVm012207@sana.init-main.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410040606.i9466UVm012207@sana.init-main.com> cc: freebsd-fs@FreeBSD.ORG cc: Boris Popov cc: freebsd-current@FreeBSD.ORG cc: gemini@geminix.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:18:20 -0000 On Mon, Oct 04, 2004, 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? Many applications use the file's inode number and the filesystem device number to uniquely identify files, since this information can be easily and portably extracted via stat(2). IIRC, unionfs has always used the upper layer's device number, which is arguably wrong. I think the main consumer of fsids is NFS, which uses fsids along with i-numbers to construct file handles. umount(..., MNT_BYFSID) is another interface that uses fsids.