From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 07:07:29 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 F2B7716A4CE; Mon, 4 Oct 2004 07:07:28 +0000 (GMT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE5D943D45; Mon, 4 Oct 2004 07:07:27 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost.init-main.com [127.0.0.1]) by sana.init-main.com (8.13.1/8.13.1) with ESMTP id i9475jwq012503; Mon, 4 Oct 2004 16:05:45 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200410040705.i9475jwq012503@sana.init-main.com> To: Uwe Doering From: takawata@jp.freebsd.org In-reply-to: Your message of "Mon, 04 Oct 2004 08:26:14 +0200." <4160ED06.6070603@geminix.org> Date: Mon, 04 Oct 2004 16:05:45 +0900 Sender: takawata@init-main.com cc: freebsd-fs@FreeBSD.org cc: Boris Popov cc: das@FreeBSD.org 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: Mon, 04 Oct 2004 07:07:29 -0000 In message <4160ED06.6070603@geminix.org>, Uwe Doering wrote: >Takanori Watanabe wrote: >> In message <20041004053106.GQ88303@vertex.kz>, Boris Popov wrote: >> >>>On Sun, Oct 03, 2004 at 11:06:42PM +0200, Uwe Doering wrote: >>> >>>>>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. >>> >>> Exactly, one never knows what parts of metadata used by applications. >>>I can confirm that ino are ought to be unique inside filesystem, otherwise >>>some programs will fail in a very obscure ways. >> >> Ok, the issue Uwe says is when underlying filesystem and >> wrapping filesystem are diffent and if there are two files >> with same identifier exists. >> And the issue I want to fix is when underlying filesystem and >> wrapping filesystem are same so getcwd routine failed to distinguish >> the mount point. >> >> So it can be solved by translating fsid if the fsid of a file is same as >> that of mountpoint. True? > >Correct. In this case the inode number is guaranteed to be unique. >This might be okay as a local patch, but it is IMHO not a fix suited for >FreeBSD in general. Ok. How about this? Index: union_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/unionfs/union_vnops.c,v retrieving revision 1.109 diff -u -r1.109 union_vnops.c --- union_vnops.c 2 Oct 2004 17:17:04 -0000 1.109 +++ union_vnops.c 4 Oct 2004 07:04:38 -0000 @@ -951,6 +951,8 @@ error = VOP_GETATTR(vp, vap, ap->a_cred, ap->a_td); if (error) return (error); + ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; + /* XXX isn't this dangerous without a lock? */ union_newsize(ap->a_vp, vap->va_size, VNOVAL); } @@ -972,7 +974,6 @@ union_newsize(ap->a_vp, VNOVAL, vap->va_size); } - ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; if ((vap != ap->a_vap) && (vap->va_type == VDIR)) ap->a_vap->va_nlink += vap->va_nlink;