From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 18:32:26 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 DF61516A4CE; Sun, 3 Oct 2004 18:32:26 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0624943D1D; Sun, 3 Oct 2004 18:32:26 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i93IWbYw008147; Sun, 3 Oct 2004 14:32:37 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i93IWbHU008146; Sun, 3 Oct 2004 14:32:37 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 3 Oct 2004 14:32:37 -0400 From: David Schultz To: Takanori Watanabe Message-ID: <20041003183237.GA8100@VARK.MIT.EDU> Mail-Followup-To: Takanori Watanabe , Uwe Doering , freebsd-fs@FreeBSD.ORG, bp@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410031805.i93I5JNZ009076@sana.init-main.com> cc: freebsd-fs@FreeBSD.ORG cc: bp@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG cc: Uwe Doering 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:32:27 -0000 On Mon, Oct 04, 2004, Takanori Watanabe wrote: > >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. I didn't pursue this before because I was concerned that it would introduce cache consistency issues between the union vnode and the underlying vnode. But I guess all vnops ultimately wind up at the underlying vnode, so this hopefully isn't an issue...