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

[Bruce Evans]

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

Bruce