On 16-03-13 11:11 PM, Michael McConville wrote:
It seems that chown(1) will write to a file even if it already has the
desired ownership. The below patch causes it to skip the write when
there would be no change. The best I could tell, the fts_read(3) and
fchownat(3) logic agree on whether to follow symlinks in all cases, so
there's no need to execute a useless write when certain options are
specified.
I get a speedup of 5-10% on SSDs, and probably more on a slow storage
HD. This is when all the files are already owned by the specified user.
I think this is a common case, as chown is often used to "comb out"
offending files, ensure that a server can access everything in /var/www,
etc.
The APIs involved are not simple and there's potential for subtle
breakage, so this only an initial patch. I'm interested to hear what
more experienced people think.
If it's worthwhile, a similar approach can probably be applied to
chmod(1) et al. as well.
If this becomes the default behaviour, please allow a way to revert to
the previous behaviour, as this change would break several real systems
I'm aware of, including one I currently manage.
There are many NFS implementations where chown(2)/chmod(2) do magic on
the back end, ranging from "clearing the UID/GID translation cache"
(huh?) to resetting the file to default ACLs (e.g. Sun/Oracle
"Fishworks"-series NAS systems).
To rephrase: chown(file,$owner,$gid) when the file is already owned by
$owner:$gid is _not necessarily_ a no-op on all filesystems.
As an extra option, though, sure; I know which filesystems this
behaviour matters on and which it doesn't, but there's no realistic way
to embed that knowledge into chmod - there's no standard query to ask an
NFS server "do you practice voodoo?", for better or for worse...
GNU already uses "-c" for a somewhat-related behaviour (modifies the
output of -v, but not the internal behaviour IIRC); I can't quickly find
anything similar anywhere else.
FWIW, full support for NFSv4 and NFS ACLs would eliminate the dependency
on chown/chmod/etc. doing voodoo on the remote NFS server, but there are
other, non-NFS, remote filesystems that do similar things. I can't
remember if OpenBSD still supports any of them, though.
-Adam
