Your CVS fix 1.109 to union_vnops.c

[Boris Popov]

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