Re: Your CVS fix 1.109 to union_vnops.c

In message <41601BE0.4050401_at_geminix.org>, Uwe Doering $B$5$s$$$o$/(B:
>takawata_at_jp.freebsd.org wrote:
>> In message <415FC1A1.3020502_at_geminix.org>, Uwe Doering wrote:
>> 
>>>Hi there,
>>>
>>>with regard to your above mentioned fix you may be interested in reading 
>>>this short discussion, especially my answer to the original article:
>>>
>>>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=116615+0+archive/2004/freebsd-s
>table/20040613.freebsd-stable
>> 
>> Thank you for your comment.
>> 
>> The code is what nullfs do.
>> 
>> static int
>> null_getattr(ap)
>>         struct vop_getattr_args /* {
>>                 struct vnode *a_vp;
>>                 struct vattr *a_vap;
>>                 struct ucred *a_cred;
>>                 struct thread *a_td;
>>         } */ *ap;
>> {
>>         int error;
>> 
>>         if ((error = null_bypass((struct vop_generic_args *)ap)) != 0)
>>                 return (error);
>> 
>>         ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0];
>>         return (0);
>> }
>> 
>> I'm pleased if you explain why it is done
>> for nullfs and not for unionfs, if any.
>> IMHO, there are not so much advantage in assuming 
>> exactly same file exists in different filesystem,
>> if the entity is same.
>
>'nullfs' has only one underlying file system, so replacing the file 
>system id doesn't break the uniqueness of the va_fsid/va_fileid pair. 
>The latter is the inode number in case of UFS.
>
>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.

>> But I want to hear from FS gurus. 
>> I found that I reverted the change at CVS rev  1.62.
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/unionfs/union_vnops.c.diff?
>r1=1.61&r2=1.62
>
>Right.  Better safe than sorry.

Same change are applyed in nullfs and reverted by bp_at_.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/nullfs/null_vnops.c.diff?r1=1.33&r2=1.34
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/nullfs/null_vnops.c.diff?r1=1.40&r2=1.41