On 28/10/12 06:32, Rasmus Lerdorf wrote:
On 10/27/2012 03:50 PM, Stas Malyshev wrote:
Hi!
An APC-level fix might be to fix the include_once/require_once override
implementation to go to the cache first to see if the inode is there and
pull out the cached realpath and use that to check against the
included_files list. The downside is that we will likely end up with 2
cache lookups on every include_once.
Comparing inodes sounds like a good idea for APC. Or, rather, comparing
device,inode tuples. However, it should be able to fall back to
comparing paths for files that have no inode.
However, this may lead to BC break in (admittedly very unlikely)
scenario of file hardlinked under two different names.
Ok, I have a working implementation which uses the normal APC cache
lookup mechanism which by default will use an inode lookup, so through
that we get the device+inode check, and it will then pull the realpath
instead of going through VCWD_REALPATH() to get a possibly incorrect
one. See the attached patch. This takes care of the hardlink scenario as
well because it checks both the inode and the cached path. Anyone see
any holes in this approach?
From the perspective of a production sysadmin, I've always just set
apc.stat=0 but then cleared the cache following any change. This gives
the best of both worlds: the performance dividend of no stat'ing and
avoiding the weird gremlins that sometimes occurred if I didn't flush
the cache. The one-off hit for repriming the cache again is pretty
small and the "release from dev to live" cycle isn't a common event.
For a multi-app configuration, it would be a very simple matter to write
an admin script which clears the cache based on some REGEX filename
match, so that this could be integrated into application release scripts.
So I guess what I am suggesting is that the best way to address this
would not be to complicate the code further, but simply to document the
correct administration practice to follow if you are attempting to do
hot re-symlinking on a production system.
But to Rasmus Q, IMO since the cache is (possibly SMP multi-core)
server-specific, the device+inode identity for a given file is unique --
at least for that server / APC instance, *unlike* the equivalent
situation in Apache Server where device+inode is sometimes used to
generate ETags on a server-farm and this causes issues with false
(client-side) cache-misses.
Terry
