Re: 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