From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 05:31:12 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 F075F16A4CE; Mon, 4 Oct 2004 05:31:12 +0000 (GMT) Received: from relay.butya.kz (butya-gw.butya.kz [212.19.129.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0880243D2F; Mon, 4 Oct 2004 05:31:11 +0000 (GMT) (envelope-from bp@butya.kz) Received: from lion.butya.kz (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with SMTP id A06715C9F; Mon, 4 Oct 2004 12:31:06 +0700 (ALMST) Received: from relay.butya.kz (localhost [127.0.0.1]) by localhost.butya.kz (Postfix) with ESMTP id 79AEC5C9D; Mon, 4 Oct 2004 12:31:06 +0700 (ALMST) Received: by relay.butya.kz (Postfix, from userid 1000) id 745055C84; Mon, 4 Oct 2004 12:31:06 +0700 (ALMST) Date: Mon, 4 Oct 2004 12:31:06 +0700 From: Boris Popov To: Uwe Doering Message-ID: <20041004053106.GQ88303@vertex.kz> References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> <20041003183237.GA8100@VARK.MIT.EDU> <41605620.90407@geminix.org> <20041003200803.GA8668@VARK.MIT.EDU> <416069E2.6030403@geminix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416069E2.6030403@geminix.org> User-Agent: Mutt/1.5.6i cc: freebsd-fs@FreeBSD.ORG cc: David Schultz cc: Takanori Watanabe 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 05:31:13 -0000 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. > > As to your concern, in CURRENT this might be fixed already. There, the > unionfs vnode doesn't have an object attached. Instead, calls to > VOP_GETVOBJECT() get forwarded to the underlying file, so the same > object gets referred as for direct modifications of that file. That > should rule out any coherency problems, IMHO. > > Unfortunately, AFAIK, this fix has never been MFC'ed to 4-STABLE. The > respective CVS commits are union_subr.c (rev. 1.51) and union_vnops.c > (rev. 1.82). Correct, VOP_*VOBJECT() vnops were introduced to fill the gap in absence of UBC and should solve most of the cache coherency problems when used properly. -- Boris Popov http://rbp.euro.ru