From owner-freebsd-current@FreeBSD.ORG Sun Oct 3 20:07:52 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 001FE16A4CE; Sun, 3 Oct 2004 20:07:51 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9713D43D1D; Sun, 3 Oct 2004 20:07:51 +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 i93K832c008713; Sun, 3 Oct 2004 16:08:03 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i93K83cl008712; Sun, 3 Oct 2004 16:08:03 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 3 Oct 2004 16:08:03 -0400 From: David Schultz To: Uwe Doering Message-ID: <20041003200803.GA8668@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 20:07:52 -0000 On Sun, Oct 03, 2004, Uwe Doering wrote: > >>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. That isn't the issue. The issue is that an application might open the vnode in the unionfs mount, and another application might modify the same file in the underlying file system. If the kernel doesn't understand that it is really the same file, then cache incoherencies will occur. I'm actually not sure to what extent this is a problem already; John Heidemann's Phd thesis had a way of dealing with it, but FreeBSD doesn't do things that way AFAIK.