Date: Mon, 04 Oct 2004 09:29:29 +0200 From: Uwe Doering <gemini@geminix.org> To: takawata@jp.freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: Your CVS fix 1.109 to union_vnops.c Message-ID: <4160FBD9.10603@geminix.org> In-Reply-To: <200410040705.i9475jwq012503@sana.init-main.com> References: <200410040705.i9475jwq012503@sana.init-main.com>
next in thread | previous in thread | raw e-mail | index | archive | help
takawata@jp.freebsd.org wrote:
> In message <4160ED06.6070603@geminix.org>, Uwe Doering wrote:
>
>>Takanori Watanabe wrote:
>>[...]
>>>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;
This wouldn't be correct, either. Unionfs can be stacked, that is, you
can't even be sure for a single layer that the passed up va_fsid will
always be the same. The underlying unionfs can be comprised of two
layers on two different file systems as well, and so on. You can
override va_fsid only if the original file system id is guaranteed to be
the same for all files in that layer (single file system case).
Uwe
--
Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers
gemini@geminix.org | http://www.escapebox.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4160FBD9.10603>