On Tue, Apr 29, 2014 at 1:24 PM, Stefan Fuhrmann <
stefan.fuhrmann_at_wandisco.com> wrote:
> On Thu, Apr 24, 2014 at 11:55 AM, Philip Martin <
> philip.martin_at_wandisco.com> wrote:
>
>> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>>
>> > Since no functionality depended on the change so far, except
>> > for some extra fool-proving during hotcopy, I reverted the change
>> > in r1589518.
>>
>> svnadmin_tests.py 40 started to take advantage of your change and would
>> hang after you reverted it. The problem was
>>
>> svnadmin create repo1
>> svnadmin hotcopy repo1 repo2
>> echo repo1 > repos
>> echo repo2 >> repos
>> svnadmin freeze -F repos true
>>
>
> I'm aware of that problem. It should already be present in 1.8.x.
> But my original patch clearly broke our locking guarantees in
> some not-so-obvious-to-the-user cases, so it had to be reverted.
>
> I've changed the hotcopy UUID to avoid the hang. Could FSFS detect the
>> deadlock and return an error rather than hang?
>>
>
> If we allow for some false negatives, then yes. We could store
> the thread ID alongside the lock and test that before attempting
> to acquire it. This mechanism would need to be FSFS-internal
> only as it is unclear whether we would allow for the unknown
> overhead in all places that use svn_mutex__t.
>
> -- Stefan^2.
>
So, r1591872 adds a very small overhead to all uses of svn_mutex__t
but for that we get optional recursion everywhere.
-- Stefan^2.
Received on 2014-05-05 01:19:36 CEST