Your CVS fix 1.109 to union_vnops.c

[Uwe Doering]

David Schultz wrote:
> On Sun, Oct 03, 2004, Uwe Doering wrote:
> 
>>>>I think the three filesystem entry 
>>>>1. upper layer file
>>>>2. lower layer file
>>>>3. unionfs file
>>>>can be treated as different.
>>>
>>>I didn't pursue this before because I was concerned that it would
>>>introduce cache consistency issues between the union vnode and the
>>>underlying vnode.  But I guess all vnops ultimately wind up at the
>>>underlying vnode, so this hopefully isn't an issue...
>>
>>Applications use the synthesized unionfs vnodes. They have no knowledge 
>>of what's going on underneath. So they can't tell whether one unionfs 
>>vnode refers to a file in the upper layer, and the other to one in the 
>>lower layer.
> 
> 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.

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).

    Uwe
-- 
Uwe Doering         |  EscapeBox - Managed On-Demand UNIX Servers
gemini at geminix.org  |  http://www.escapebox.net