Re: Your CVS fix 1.109 to union_vnops.c

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-stable/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.

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

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