From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 18:06:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA2B516A4CE; Sun, 3 Oct 2004 18:06:58 +0000 (GMT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id C31EF43D2D; Sun, 3 Oct 2004 18:06:57 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost.init-main.com [127.0.0.1]) by sana.init-main.com (8.13.1/8.13.1) with ESMTP id i93I5JNZ009076; Mon, 4 Oct 2004 03:05:20 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200410031805.i93I5JNZ009076@sana.init-main.com> To: Uwe Doering In-reply-to: Your message of "Sun, 03 Oct 2004 17:33:52 +0200." <41601BE0.4050401@geminix.org> Date: Mon, 04 Oct 2004 03:05:19 +0900 From: Takanori Watanabe X-Mailman-Approved-At: Mon, 04 Oct 2004 12:02:39 +0000 cc: freebsd-fs@freebsd.org cc: bp@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2004 18:06:58 -0000 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