[saturnero@freesbie.org: Weird behaviour of mount_unionfs with executables]

[Stephan Uphoff]

Hi Bruce,

On Sun, 2005-07-03 at 21:28, Bruce Evans wrote:
> On Sun, 3 Jul 2005, Stephan Uphoff wrote:
> 
> >>> The kernel calls VOP_SETATTR to set the access time of the file.
> >>> union_fs detects that it does not have an upper layer copy of the file
> >>> to modify the attributes on and decides to copy it.
> 
> It copies the file before calling VOP_SETATTR(), so it copies the file
> even when VOP_SETATTR() is null or fails.  

Sorry for the confusion. I was referring to the call from do_execve.
I agree that the union_fs setattr implementation reacts in the way you
described. 

> Null setattr's are quite
> common for VA_EXECVE_ATIME since many file systems don't support this,
> but ffs supports it.  unionfs is one of the file systems that doesn't
> support it.  It is probably correct for it to let the underlying
> file system decide, but this gives a bug in its read-onlyness check:
> the check doesn't include VA_EXECVE_ATIME, so on exec it makes a useless
> copy even for ffs in the case that the underlying file system is mounted
> read-only.  The check is missing much more than that.  For ffs, I think
> the only other EROFS error is for the birthtime but there is no way to
> request setting only the birthtime, but there are lots of similar errors
> involving immutable files and snapshots (these return EPERM).
> 
> >> Ok, so this is just a limitation of unionfs, not the vnode pager.  You
> >> had me scared that we'd be doing a whole lot of needless disk i/o.
> >
> > YES - and it looks like just specifying noatime for the union mount
> > should fix the copy problem for FreeSBIE.
> 
> Most file systems bogusly silently ignore mount options that they don't
> understand, and unionfs's handling of noatime is no exception.  

It looks like the option is added to the mnt_flag field of the mount
point in vfs_domount. While union_fs ignores the option do_execve does
not even call setattr if either the MNT_NOATIME or MNT_RDONLY bit is set
in the mnt_flag of the filesystem of the vnode.
This should be easy to try out - but my test system is currently busy
with RELENG_5.
I am not saying that this is the right thing to do and I agree that the
bugs you mentioned above are real - but unless someone(TM) steps in and
fixes these problems in union_fs this could be a quick workaround for
freesbie (again - if it works).

> I think noatime and most other mount options shouldn't apply to unionfs anyway --
> the underlying file system should decide.  Otherwise the behaviour
> depends too much on the pathname used to access a file.

I think it is important that the behaviour is the same before and after
the copy to the upper fs. However I don't see why accessing a file
though both union_fs and directly to the upper/lower file system should
not result in different behaviours.
This being said I will be neither using nor fixing union_fs in the near
future (at least I hope so) so this is just my current opinion and
nothing more :-)

Stephan