Adding a way to disable the stat cache

Am 03.09.2021 um 16:07 schrieb Kevin Lyda kevin@lyda.ie:

On Fri, Sep 3, 2021 at 2:34 PM Christian Schneider
cschneid@cschneid.com wrote:

If I remember correctly it was about reducing the number of system calls. Is this no issue any more?
Has a quick benchmark been done to see the positive / negative impact of the stat cache for a typical application?

In the lifespan of php it really wasn't an issue unless someone was
doing something that wasn't wise - I can't think of a single reason to
stat a file in a tight loop.

How can you say "it never was a problem" if we never had to live without stat cache?
Can you back up that claim with numbers? There are some of us who run high-volume websites where system load increase could be a problem.

However more importantly the current behaviour returns bad data for
perfectly correct programs. So for example on a unix box...

<?php
passthru('touch foo');
if (is_file('foo')) {
echo "Correct\n";
}
passthru('rm foo');
if (is_file('foo')) {
echo "Incorrect\n";
}
?>

I disagree that this (with current PHP) is a correct program. The documentation at
https://www.php.net/manual/en/function.is-file.php#refsect1-function.is-file-notes https://www.php.net/manual/en/function.is-file.php
clearly states that is_file() is cached and clearstatcache() should be used.

Yes, the stat cache is a foot gun, but it was put in for a reason back in the day.

Personally I value correctness first and then performance is a
priority further down that list of attributes (security and
readability would also be higher priorities). However as the current
behaviour has existed for several decades, this change makes sure the
incorrect historical behaviour is the default.

There are two problems here:

a) Removing the stat cache altogether (which is not your proposal, I know, but it was mentioned in the thread) could lead to a performance regression. I was asking for data backing up the claim that this regression either does not exist or is small enough to not be a problem. Just saying "it never was a problem" or "modern Linux should handle this" does not give me that certainty.

b) Making it an .ini-Option seems to be a BC preserving measure but, in fact, it creates an even bigger issue: Your code snippet is correct or buggy depending on an ini-settings. Something we want to avoid as much as possible, see magic_quotes :-)

• Chris

On Fri, Sep 3, 2021 at 2:34 PM Christian Schneider
cschneid@cschneid.com wrote:

If I remember correctly it was about reducing the number of system calls. Is this no issue any more?
Has a quick benchmark been done to see the positive / negative impact of the stat cache for a typical application?

In the lifespan of php it really wasn't an issue unless someone was
doing something that wasn't wise - I can't think of a single reason to
stat a file in a tight loop.

It seems to me a typical example where the stat cache is useful would be

<?php
if (is_file($filename) && is_readable($filename)) {…}
?>

--
Christoph M. Becker

On Fri, Sep 3, 2021 at 2:34 PM Christian Schneider
cschneid@cschneid.com wrote:

If I remember correctly it was about reducing the number of system
calls. Is this no issue any more?
Has a quick benchmark been done to see the positive / negative impact of
the stat cache for a typical application?

In the lifespan of php it really wasn't an issue unless someone was
doing something that wasn't wise - I can't think of a single reason to
stat a file in a tight loop.

However more importantly the current behaviour returns bad data for
perfectly correct programs. So for example on a unix box...

<?php
passthru('touch foo');
if (is_file('foo')) {
echo "Correct\n";
}
passthru('rm foo');
if (is_file('foo')) {
echo "Incorrect\n";
}
?>

Now this is a silly toy, but imagine using is_file to see if a
graphics file exists, running an image processing program on it to
modify it, and then using a stat call to get the file length to
populate the Content-Length field - it will almost certainly be wrong.

Just to throw it out there: Maybe we should clear the stat cache when
functions in the exec family are used? Even if we allow disabling the stat
cache, I think we can easily avoid that particular footgun. And if calls to
external binaries are involved we likely don't have to worry about stat
overhead.

Regards,
Nikita