[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Fri, 19 Jun 2015 16:19:32 +0200

On Fri, Jun 19, 2015 at 11:50 AM, Branko Čibej <brane_at_wandisco.com> wrote:

> 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 ...

Yes, I'm aware of that. For FSX, we will open at most 7
file & directory handles in any fsync batch. Basically one
for everything that is part of or container for a revision.
This is in the same order of magnitude like what we use
for delta chains.

-- Stefan^2.
Received on 2015-06-19 16:20:43 CEST

This is an archived mail posted to the Subversion Dev mailing list.