Date: Mon, 4 Oct 2004 12:31:06 +0700 From: Boris Popov <bp@FreeBSD.org> To: Uwe Doering <gemini@geminix.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Your CVS fix 1.109 to union_vnops.c Message-ID: <20041004053106.GQ88303@vertex.kz> In-Reply-To: <416069E2.6030403@geminix.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041004053106.GQ88303>