Am 15.04.2012 17:02, schrieb Blair Zajac:
On 04/15/2012 07:49 AM, stef...@apache.org wrote:
Author: stefan2
Date: Sun Apr 15 14:49:21 2012
New Revision: 1326354
URL: http://svn.apache.org/viewvc?rev=1326354&view=rev
Log:
Disable the revprop cache if our sync. mechanisms are too expensive.
* subversion/include/private/svn_named_atomic.h
(svn_named_atomic__is_efficient): declare new API function
* subversion/libsvn_subr/svn_named_atomic.c
(SYNCHRONIZE_IS_FAST): new constant, set depending on system /
compiler capabilities
(svn_named_atomic__is_efficient): implement new API function
* subversion/libsvn_fs_fs/fs_fs.c
(has_revprop_cache): disable cache if sync is slow
Modified:
subversion/trunk/subversion/include/private/svn_named_atomic.h
subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
subversion/trunk/subversion/libsvn_subr/svn_named_atomic.c
+/** Returns #TRUE on platforms that don't need expensive
synchronization
+ * objects to serialize access to named atomics. If this returns
#FALSE,
+ * reading from or modifying a #svn_named_atomic__t may be as expensive
+ * as a file system operation.
That is assuming it's a local file system? It still may be faster
than getting a file from NFS, which people will host repositories on.
The current implementation has a number of limitations:
* the repository must only be written to by 1.8+ servers
* revprop caching must be enabled on all of them or none
* all 1.8 servers accessing the repository must reside on
the same machine
* the machine / compiler should provide fast low-level
synchronization mechanisms
For the time being, I think these are acceptable because
those admins that care enough about the the possible
reduction in I/O will also understand its limitations.
Revprop packing will only be efficient with some sort of
caching mechanism to avoid re-reading large-ish files
over and over again. On the other hand, it may open the
door to less restrictive update checks once we've got a
format bump anyway.
-- Stefan^2.
