From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 13:13:24 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D58D016A4CE for ; Wed, 9 Jun 2004 13:13:24 +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 39AA143D46 for ; Wed, 9 Jun 2004 13:13:24 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <40C70CF0.5080304@geminix.org> Date: Wed, 09 Jun 2004 15:13:20 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040119 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <200406080903.i5893AO01551@Mail.NOSPAM.DynDNS.dK> In-Reply-To: <200406080903.i5893AO01551@Mail.NOSPAM.DynDNS.dK> 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 1BY2tO-000PnX-00; Wed, 09 Jun 2004 15:13:22 +0200 Subject: Re: patch for unionfs mounts X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 13:13:25 -0000 Barry Bouwsma wrote: > [...] > Without this patch, a getcwd() call (from csh, and others, but > apparently not bash) returns the upper unionfs-mounted layer. > This breaks things like `make world' and its ilk when one mounts, > say, /usr/source-hacks atop /usr/src (perhaps additional intermediate > directories, like /usr/local/source-hacks, are necessary to demonstrate > the problem). > > In other words, when one is in /usr/src (or /usr/local/source-hacks) > and asks for getcwd(), several shells return /usr/local/source-hacks > instead of /usr/src, without this patch, which as noted breaks > buildworlds. (Or perhaps in subdirectories -- I don't recall) > > After applying this patch, a getcwd() call returns /usr/src, no > matter what shell, which allows buildworlds to complete. I've > had this patch for years, and never had any problems with it. > I've only had problems without including it. > > The trivial one-liner patch is as follows: > > --- union_vnops.c-ORIG Tue Jan 13 22:20:02 2004 > +++ union_vnops.c Tue May 11 14:49:02 2004 > @@ -963,6 +963,8 @@ > 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; > return (0); > > > > > As noted, without this, builds fail with a union-mounted > directory of hacks atop the pristine virginal /usr/src. With > this patch, no ill effects have been noted. I'm afraid there is a problem with this approach. 'va_fsid' and 'va_fileid' end up as 'st_dev' and 'st_ino' on the application level ("struct stat"). The combination of these two variables is supposed to be unique, at least by convention. Software relies on the assumption that if 'st_dev' and 'st_ino' are identical for two files it is actually the same file. Now, by forcing 'va_fsid', and therefore 'st_dev', to the same value (the unionfs mount's file system id) regardless of which device (file system) the file is actually located on this patch introduces ambiguity. There can be two different files with the same 'va_fileid' value (the inode number, for instance), living on two different file systems, that now appear to be the same file due to the "fake" value in 'va_fsid'. This is going to break existing software. So I recommend against committing this patch to the FreeBSD CVS repository. I have no idea how else to fix your initial problem, but this patch is not the way to do it, IMHO. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net