freebsd stable - Jun 2004 - patch for unionfs mounts

[drop the above ipv6-only address that only sometimes works from the
 recipients and I'll catch up later from the archives, thanks]


Salutations, comrades.

I've got a bunch of patches that I apply to my 4.x source before
building world, some of which seem to be worthy of merging into
the official RELENG_4 branch.  I'm wondering if someone would be
interested in this:

I've applied this particular patch for an eternity without quite
remembering why.  After failing to apply it, it's clear, and rather
worthy of inclusion.  This is a unionfs patch, that I pulled from
either the PR database or from the mailing lists several years ago.

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.

Sorry if this is in a PR that hasn't yet been addressed (I was
too lazy to grep all the PRs or the entire mailing list archives).
And sorry if this should be another PR (I'm offline and can't
access the official submit site when I have time to spare).  If
others use this, with or without problems, that would be good to
know too.


thanks
barry bouwsma

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