> -----Original Message-----
> From: stef...@apache.org [mailto:stef...@apache.org]
> Sent: woensdag 17 juni 2015 12:09
> To: comm...@subversion.apache.org
> Subject: 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
>
> Author: stefan2
> Date: Wed Jun 17 10:09:12 2015
> New Revision: 1685985
>
> URL: http://svn.apache.org/r1685985
> Log:
> On the fsx-1.10 branch:
> Introduce a new infrastructure to FSX that allows us to do efficient fsyncs.
>
> It basically uses a thread pool to execute multiple fsyncs concurrently.
> Interestingly, this generic implementation is faster on Linux than even the
> POSIX-provided aio_fsync functionality on the same system. As a centralized
> mechanism for scheduling fsyncs it also takes care of preventing redundant
> flushes.
>
> With this commit, FSX does not actually use the new capabilities. That will
> be in the following commits.
Would it be possible to implement this on filehandles on Windows, instead of
just on filenames.
Reopening a file that has just been closed is typically not fast on Windows, as
virusscanners and file indexers are often fighting to use the same files. The
next open operation then sometimes has to wait (when using OPLOCKS) or has to
be retried (when the other process opens the file in a way that concurrent
writes are denied).
All of this can be avoided by just flushing the filehandle we already had when
the file was open for writing. By closing and re-opening we are doing a lot of
unneeded work and add a lot of potential race conditions.
Bert
