From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 15:34:09 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 4298716A4CE; Sun, 3 Oct 2004 15:34:09 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id F362B43D41; Sun, 3 Oct 2004 15:34:08 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <41601BE0.4050401@geminix.org> Date: Sun, 03 Oct 2004 17:33:52 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041002 X-Accept-Language: en-us, en MIME-Version: 1.0 To: takawata@jp.freebsd.org References: <200410031429.i93ET8Sf008251@sana.init-main.com> In-Reply-To: <200410031429.i93ET8Sf008251@sana.init-main.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1CE8N5-0003HN-00; Sun, 03 Oct 2004 17:34:00 +0200 X-Mailman-Approved-At: Mon, 04 Oct 2004 12:02:39 +0000 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 15:34:09 -0000 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-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@geminix.org | http://www.escapebox.net