From owner-freebsd-fs@FreeBSD.ORG Sun Oct 3 21:06:46 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E2E116A4CE; Sun, 3 Oct 2004 21:06:46 +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 D9C9A43D3F; Sun, 3 Oct 2004 21:06:45 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <416069E2.6030403@geminix.org> Date: Sun, 03 Oct 2004 23:06:42 +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: David Schultz References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> <20041003183237.GA8100@VARK.MIT.EDU> <41605620.90407@geminix.org> <20041003200803.GA8668@VARK.MIT.EDU> In-Reply-To: <20041003200803.GA8668@VARK.MIT.EDU> 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 1CEDZ6-000A5x-00; Sun, 03 Oct 2004 23:06:45 +0200 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-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2004 21:06:46 -0000 David Schultz wrote: > 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. Okay, but that's a different matter. What I was addressing at the start of this discussion is an ambiguity issue with meta data, that is, information that ends up in stat(2) and friends. As to your concern, in CURRENT this might be fixed already. There, the unionfs vnode doesn't have an object attached. Instead, calls to VOP_GETVOBJECT() get forwarded to the underlying file, so the same object gets referred as for direct modifications of that file. That should rule out any coherency problems, IMHO. Unfortunately, AFAIK, this fix has never been MFC'ed to 4-STABLE. The respective CVS commits are union_subr.c (rev. 1.51) and union_vnops.c (rev. 1.82). Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net