Re: svn commit: r1331763 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.h fs_fs.c

[Stefan Fuhrmann <eq...@web.de>]

Am 28.04.2012 16:41, schrieb Daniel Shahaf:
> stefan2@apache.org wrote on Sat, Apr 28, 2012 at 13:48:00 -0000:
>> Author: stefan2
>> Date: Sat Apr 28 13:48:00 2012
>> New Revision: 1331763
>>
>> URL: http://svn.apache.org/viewvc?rev=1331763&view=rev
>> Log:
>> The lifetime of the shared-memory based named atomics used for
>> revprop generation communication and storage may be as short as
>> that of the svn_fs_t. Cached revprops may live as long as the process,
>> though. Therefore, we must store the revprop generation on disk
>> and re-read it when we encounter un-initialized (having only the
>> default value of 0) the named atomics.
>>
>> Please note that the revprop generation file is optional an may be
>> removed or remain unchanged when being used with older servers.
>> Therefore, no format bump is necessary.
> I'm lost.  The cache lives as long as the process, the generation as
> long as the svn_fs_t, therefore you cache the generation on-disk?  In
> a file whose name is _not_ keyed on the process (or even the machine)?
>
> This sounds wrong.  (For example, if two processes on the same machine
> both swap out their generation to a file, and then read it back, one of
> them will get the wrong value.)  Isn't the right solution to store the
> generation in memory of the same lifetime as the cache itself?
>
The problem is that there is 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 not an option, too.

So, we store the new revprop generation as part of each
setrevprop call, i.e. this write will be serialized and the
write order be kept by the repository write lock.

The only racy situation occurs when the data is being read
again but the first one 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.

-- Stefan^2.

Re: svn commit: r1331763 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.h fs_fs.c

[Greg Stein <gs...@gmail.com>]

On Jun 4, 2012 5:38 AM, "Stefan Fuhrmann" <eq...@web.de> wrote:
>
> Am 30.04.2012 21:20, schrieb Greg Stein:
>
>> On Sun, Apr 29, 2012 at 08:15, Stefan Fuhrmann<eq...@web.de>  wrote:
>>>
>>> ...
>>> The problem is that there is 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 not an option, too.
>>>
>>> So, we store the new revprop generation as part of each
>>> setrevprop call, i.e. this write will be serialized and the
>>> write order be kept by the repository write lock.
>>>
>>> The only racy situation occurs when the data is being read
>>> again but the first one 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.
>>
>> Is all the above written into some comments or docstrings? It would be
>> nice to preserve information in the code rather than mailing lists :-)
>
>
> Added to docstrings in r1345872.

Cool. Thanks!

Re: svn commit: r1331763 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.h fs_fs.c

[Stefan Fuhrmann <eq...@web.de>]

Am 30.04.2012 21:20, schrieb Greg Stein:
> On Sun, Apr 29, 2012 at 08:15, Stefan Fuhrmann<eq...@web.de>  wrote:
>> ...
>> The problem is that there is 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 not an option, too.
>>
>> So, we store the new revprop generation as part of each
>> setrevprop call, i.e. this write will be serialized and the
>> write order be kept by the repository write lock.
>>
>> The only racy situation occurs when the data is being read
>> again but the first one 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.
> Is all the above written into some comments or docstrings? It would be
> nice to preserve information in the code rather than mailing lists :-)

Added to docstrings in r1345872.

-- Stefan^2.

Re: svn commit: r1331763 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.h fs_fs.c

[Greg Stein <gs...@gmail.com>]

On Sun, Apr 29, 2012 at 08:15, Stefan Fuhrmann <eq...@web.de> wrote:
>...
> The problem is that there is 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 not an option, too.
>
> So, we store the new revprop generation as part of each
> setrevprop call, i.e. this write will be serialized and the
> write order be kept by the repository write lock.
>
> The only racy situation occurs when the data is being read
> again but the first one 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.

Is all the above written into some comments or docstrings? It would be
nice to preserve information in the code rather than mailing lists :-)

Cheers,
-g