patch for unionfs mounts

[Barry Bouwsma]

Uwe Doering wrote:

> > +++ union_vnops.c	Tue May 11 14:49:02 2004
> > +       ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0];

> 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'.

Hmmm, thanks for the explanation.  Too good to be true...

It sounds as if I've been lucky since the directories I've
unionfs-mounted have been contained within one filesystem
(/usr/local/source-hacks atop /usr/src; /usr being common).


> 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.

So I'm fixing one problem (for myself), but potentially causing
others -- for example, if I had /var/source-hacks mounted atop
/usr/src then I'd definitely be seeing problems.  Is this correct?


By the way, I finally grepped my archives in case I had overlooked
discussion about this patch when originally propsed, and found
the original message from 25.Feb 2002, and one followup.
archive/2002/freebsd-hackers/20020303.freebsd-hackers.gz
Message-Id: <200202251435.XAA91094 at shidahara1.planet.sci.kobe-u.ac.jp>
(followup in the following week's archive as
Message-Id: <200203060047.g260l4K29454 at green.bikeshed.org> )
(sorry this isn't an online-friendly clickable link)

Anyway, until a real fix can be applied, I'll keep this hack
locally (and use it carefully).  As far as alternatives, I'm
not sure if it's worth hacking csh and so on to act as bash,
or if I should look at the kernel getcwd() call, and anyway,
I'm no hacker, and lazy, and any hacks would probably also be
local-only...


Many thanks for your feedback!
barry bouwsma