Re: svn commit: r1685985 - in /subversion/branches/fsx-1.10/subversion: include/private/svn_mutex.h libsvn_fs_x/batch_fsync.c libsvn_fs_x/batch_fsync.h libsvn_fs_x/fs.c libsvn_subr/mutex.c tests/libsvn_fs_x/fs-x-pack-test.c

On 18.06.2015 21:58, Stefan Fuhrmann wrote:
> One key design element is that the batch fsync
> container owns the open files and will open them
> only once. So, it can not only guarantee that we
> don't need to reopen files for fsync but it can even
> prevent reopening files in cases where different
> functions were to open & close the same as part
> of some bigger functionality.

Just remember that we've had problems with too many open files in the
past; make sure that your design limits that number to a sane value.

To give you an idea of the kind of restriction we're talking about, this
is what the newest OSX reports by default:

    $ ulimit -a | grep 'open files'
    open files (-n) 256

Not exactly an abundance ...

-- Brane
Received on 2015-06-19 11:50:10 CEST