Your CVS fix 1.109 to union_vnops.c
takawata at jp.freebsd.org
takawata at jp.freebsd.org
Mon Oct 4 00:07:29 PDT 2004
In message <4160ED06.6070603 at geminix.org>, Uwe Doering wrote:
>Takanori Watanabe wrote:
>> In message <20041004053106.GQ88303 at 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;
More information about the freebsd-fs
mailing list