Am 15.04.2012 17:02, schrieb Blair Zajac:
> On 04/15/2012 07:49 AM, stefan2_at_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.
Received on 2012-04-15 19:40:56 CEST