From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 07:50:57 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 6B56316A4CE; Mon, 4 Oct 2004 07:50:57 +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 239A843D5D; Mon, 4 Oct 2004 07:50:57 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <416100D9.10809@geminix.org> Date: Mon, 04 Oct 2004 09:50:49 +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: takawata@jp.freebsd.org References: <200410040705.i9475jwq012503@sana.init-main.com> <4160FBD9.10603@geminix.org> In-Reply-To: <4160FBD9.10603@geminix.org> 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 1CENcR-000PA7-00; Mon, 04 Oct 2004 09:50:52 +0200 X-Mailman-Approved-At: Mon, 04 Oct 2004 12:02:39 +0000 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:50:57 -0000 Uwe Doering wrote: > takawata@jp.freebsd.org wrote: >> >>[...] >> 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). Since you mentioned nullfs earlier on, it just occured to me that overriding va_fsid in nullfs is wrong, too. You can have a nullfs mount with an underlying unionfs, so the passed up va_fsid isn't guaranteed to be the same in this case, either, and therefore must not be overridden. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net