On Mon, Jun 04, 2012 at 08:46:17AM -0000, stef...@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!
