On Thu, Nov 6, 2008 at 7:55 AM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> On Thu, Nov 6, 2008 at 1:35 AM, David Glasser <glasser_at_davidglasser.net> wrote:
>
>> There's a lock around appending to the proto-rev file, yes. And it
>> does write a bunch of little files for noderevs, directory listings,
>> and props, and gloms them on at finalization time, yes. But there are
>> no locks around editing the little files themselves; so for example,
>> if concurrent processes make two files in a directory at the same
>> time, there can be a race condition and only one will end up in the
>> listing. This situation isn't possible if you only access a
>> transaction from a single process (say, via the commit editor).
>
> But if all writes go through a single process, that sort of defeats
> the goal of saturating the bandwidth with parallel PUTs. Maybe it
> would be a worthy goal to make FSFS safe? I know it's something we'll
> have to do for libsvn_fs_bigtable.
Do we know that "saturating the pipe" will give the best performance?
We (CollabNet) are frequently hearing complaints of WAN performance
lately and it has been suggested that a single request would perform
better in that environment because:
a) the pipe is not that big
b) the latency on turnarounds is the biggest killer of performance
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-06 15:05:18 CET