On Mon, Jun 04, 2012 at 08:46:17AM -0000, stefan2_at_apache.org wrote:
> Author: stefan2
> Date: Mon Jun 4 08:46:16 2012
> New Revision: 1345872
>
> URL: http://svn.apache.org/viewvc?rev=1345872&view=rev
> Log:
> Explain how SHM limitations force us to store the revprop generation in disk
> and why that code is safe. Docstring improvement only.
>
> * subversion/libsvn_fs_fs/fs_fs.c
> (revprop caching): add technical background info
>
> Suggested by: gstein
>
> Modified:
> subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
>
> Modified: subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c?rev=1345872&r1=1345871&r2=1345872&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c (original)
> +++ subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c Mon Jun 4 08:46:16 2012
> @@ -2810,6 +2810,9 @@ svn_fs_fs__rev_get_root(svn_fs_id_t **ro
>
> /* Revprop caching management.
> *
> + * Mechanism:
> + * ----------
> + *
> * Revprop caching needs to be activated and will be deactivated for the
> * respective FS instance if the necessary infrastructure could not be
> * initialized. In deactivated mode, there is almost no runtime overhead
> @@ -2835,6 +2838,27 @@ svn_fs_fs__rev_get_root(svn_fs_id_t **ro
> *
> * The overhead for the second and following accesses to revprops is
> * almost zero on most systems.
> + *
> + *
> + * Tech aspects:
> + * -------------
> + *
> + * A problem is that we need to provide a globally available file name to
> + * back the SHM implementation on OSes that need it. We can only assume
> + * write access to some file within the respective repositories. Because
> + * a given server process may access thousands of repositories during its
> + * lifetime, keeping the SHM data alive for all of them is also not an
> + * option.
> + *
> + * So, we store the new revprop generation on disk as part of each
> + * setrevprop call, i.e. this write will be serialized and the write order
> + * be guaranteed by the repository write lock.
> + *
> + * The only racy situation occurs when the data is being read again by two
> + * processes concurrently but in that situation, the first process to
> + * finish that procedure is guaranteed to be the only one that initializes
> + * the SHM data. Since even writers will first go through that
> + * initialization phase, they will never operate on stale data.
> */
>
> /* Read revprop generation as stored on disk for repository FS. The result
>
Stefan, this reminds me that I've been meaning to ask you a question:
Could you please check whether what I did for 'svnadmin hotcopy' and the
revprop cache is ok? See r1335543. Thanks!
Received on 2012-06-04 12:44:27 CEST