Your CVS fix 1.109 to union_vnops.c

[Uwe Doering]

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 case of a stat(2), for instance, if va_fsid is to be overridden by 
the va_fsid of the unionfs' mount, unionfs would need to generate and 
manage its own (unique) file numbers as well, instead of passing 
va_fileid of the underlying layer unchanged. Otherwise you get the 
ambiguity I pointed out.

    Uwe
-- 
Uwe Doering
gemini at geminix.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3168 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20041003/0498f5be/smime.bin