Date: Mon, 04 Oct 2004 16:05:45 +0900 From: takawata@jp.freebsd.org To: Uwe Doering <gemini@geminix.org> Cc: freebsd-current@FreeBSD.org Subject: Re: Your CVS fix 1.109 to union_vnops.c Message-ID: <200410040705.i9475jwq012503@sana.init-main.com> In-Reply-To: Your message of "Mon, 04 Oct 2004 08:26:14 %2B0200." <4160ED06.6070603@geminix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410040705.i9475jwq012503>