Date: Mon, 04 Oct 2004 03:05:19 +0900 From: Takanori Watanabe <takawata@init-main.com> To: Uwe Doering <gemini@geminix.org> Cc: freebsd-current@freebsd.org Subject: Re: Your CVS fix 1.109 to union_vnops.c Message-ID: <200410031805.i93I5JNZ009076@sana.init-main.com> In-Reply-To: Your message of "Sun, 03 Oct 2004 17:33:52 %2B0200." <41601BE0.4050401@geminix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <41601BE0.4050401@geminix.org>, Uwe Doering さんいわく: >takawata@jp.freebsd.org wrote: >> In message <415FC1A1.3020502@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@. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410031805.i93I5JNZ009076>