Re: Your CVS fix 1.109 to union_vnops.c

On Sun, Oct 03, 2004, Uwe Doering wrote:
> David Schultz wrote:
> >On Mon, Oct 04, 2004, Takanori Watanabe wrote:
> >
> >>>With 'unionfs' you can have underlying files from two different layers 
> >>>(upper and lower) on two different file systems which may, by 
> >>>coincidence, have the same inode number.  Now, if you override the real 
> >>>va_fsid with that of the 'unionfs' mount you'll end up with two 
> >>>'unionfs' vnodes that appear to represent the same file (a hard link, 
> >>>for instance), but in reality the files are different entities. 
> >>>Obviously, both the kernel and applications might draw wrong conclusions 
> >>>in this case.
> >>
> >>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.

In my previous message I was confusing two issues, so please allow
me to clarify.  One issue is that NFS uses the fsid to look up
vnodes, so it isn't clear to me what effect this change might have
over NFS-exported unionfs mounts.  (A while ago they didn't work
anyway, but I thought that was fixed.)

The other issue is cache coherency between the upper and lower
vnodes, which I think unionfs gets wrong when mmap() is
involved---I think it needs its own (get|put)pages() that proxy
the request to the correct layer.