From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 21:01:45 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 CC07316A4CE; Sun, 3 Oct 2004 21:01:45 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B1CE43D2D; Sun, 3 Oct 2004 21:01:45 +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 i93L1vFc009209; Sun, 3 Oct 2004 17:01:57 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i93L1uLD009208; Sun, 3 Oct 2004 17:01:56 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 3 Oct 2004 17:01:56 -0400 From: David Schultz To: Uwe Doering Message-ID: <20041003210156.GA9127@VARK.MIT.EDU> Mail-Followup-To: Uwe Doering , Takanori Watanabe , freebsd-fs@FreeBSD.ORG, bp@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> <20041003183237.GA8100@VARK.MIT.EDU> <41605620.90407@geminix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41605620.90407@geminix.org> cc: freebsd-fs@FreeBSD.ORG cc: bp@FreeBSD.ORG cc: Takanori Watanabe 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 21:01:46 -0000 On Sun, Oct 03, 2004, Uwe Doering wrote: > David Schultz wrote: > >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... > > Applications use the synthesized unionfs vnodes. They have no knowledge > of what's going on underneath. So they can't tell whether one unionfs > vnode refers to a file in the upper layer, and the other to one in the > lower layer. In my previous message I was confusing two issues, so please allow me to clarify. One issue is that NFS uses the fsid to look up vnodes, so it isn't clear to me what effect this change might have over NFS-exported unionfs mounts. (A while ago they didn't work anyway, but I thought that was fixed.) The other issue is cache coherency between the upper and lower vnodes, which I think unionfs gets wrong when mmap() is involved---I think it needs its own (get|put)pages() that proxy the request to the correct layer.