Re: svn commit: r1578176 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.c fs.h fs_fs.c fs_fs.h pack.c
On 17 March 2014 03:09, <stefan2_at_apache.org> wrote:
> Author: stefan2
> Date: Sun Mar 16 23:09:45 2014
> New Revision: 1578176
> URL: http://svn.apache.org/r1578176
> Model the FSFS pack lock similarly to our other file based locks in FSFS.
> This gives us proper mutex functionality should multiple threads try to
> pack the same repo at the same time.
> * subversion/libsvn_fs_fs/fs.h
> (fs_fs_shared_data_t): Add a thread mutex alongside the file lock.
> * subversion/libsvn_fs_fs/fs.c
> (fs_serialized_init): Initialize the new mutex.
> * subversion/libsvn_fs_fs/fs_fs.h
> (svn_fs_fs__get_lock_on_filesystem): Privatize again.
> (svn_fs_fs__with_pack_lock): New lock handling function similar
> to what we do for the other locks.
> * subversion/libsvn_fs_fs/fs_fs.c
> (path_pack_lock): New utility function.
> (svn_fs_fs__get_lock_on_filesystem): Rename back to ...
> (get_lock_on_filesystem): ... this again.
> (with_some_lock_file): Update caller.
> (svn_fs_fs__with_pack_lock): Implement the new lock function.
> * subversion/libsvn_fs_fs/pack.c
> (svn_fs_fs__pack): Use the new pack lock handling function.
> Suggested by: ivan
Thanks for reworking this.
But with new code is more clear that separate pack lock break
concurrent svnadmin hotcopy: hotcopy operation only takes write-lock,
not taking pack-lock. Thus we Subversion hotcopy operation may copy
partially packed repository.
CTO | VisualSVN | http://www.visualsvn.com
Received on 2014-04-19 12:06:03 CEST
This is an archived mail posted to the Subversion Dev