Re: svn commit: r1627946 - /subversion/trunk/subversion/libsvn_fs_x/cached_data.c

[Branko Čibej <br...@wandisco.com>]

On 27.09.2014 12:44, stefan2@apache.org wrote:
> Author: stefan2
> Date: Sat Sep 27 10:44:13 2014
> New Revision: 1627946

> +      /* Clear it the ITERPOOL once in a while.  Doing it too frequently
> +       * renders the FILE_HINT ineffective.  Doing too infrequently, may
> +       * leave us with too many open file handles. */


This makes me wonder: there's no substantial difference between clearing
the pool (and closing file) every 16 iterations, or doing that on every
iteration. So, what's magical about 16, do we actually know how many
files we keep open, does the code try to gracefully handle running out
of file handles, and if not, does the whole pack operation go south when
we do run out?

-- Brane

Re: svn commit: r1627946 - /subversion/trunk/subversion/libsvn_fs_x/cached_data.c

[Stefan Fuhrmann <st...@wandisco.com>]

On Sun, Sep 28, 2014 at 12:41 AM, Branko Čibej <br...@wandisco.com> wrote:

> On 27.09.2014 12:44, stefan2@apache.org wrote:
> > Author: stefan2
> > Date: Sat Sep 27 10:44:13 2014
> > New Revision: 1627946
>
> > +      /* Clear it the ITERPOOL once in a while.  Doing it too frequently
> > +       * renders the FILE_HINT ineffective.  Doing too infrequently, may
> > +       * leave us with too many open file handles. */
>
>
> This makes me wonder: there's no substantial difference between clearing
> the pool (and closing file) every 16 iterations, or doing that on every
> iteration. So, what's magical about 16, do we actually know how many
> files we keep open, does the code try to gracefully handle running out
> of file handles, and if not, does the whole pack operation go south when
> we do run out?
>

No, there is nothing magical about that number; it's just my
value of "once in a while". r1628083 should make that clear now.

-- Stefan^2.