> -----Original Message-----
> From: Hyrum K. Wright [mailto:hyrum_wright_at_mail.utexas.edu]
> Sent: maandag 16 februari 2009 23:18
> To: Bob Archer
> Cc: Ruslan Sivak; Bert Huijben; Bolstridge, Andrew;
> users_at_subversion.tigris.org
> Subject: Re: Speeding up workspace
>
> On Feb 13, 2009, at 4:09 PM, Bob Archer wrote:
>
> >
> >>> I know, wait for 1.7... but I want it all... and I want it NOW!
> >>
> >> Patches welcome. :P
> >>
> >> -Hyrum
> >
> > I thought someone in this thread said he offered a patch to move to a
> > single lock file per folder and was told they didn't want to put it
> > into
> > 1.6 and the it would be moot for 1.7?
>
> (Sorry it took a while to respond...working on 1.6 release stuff.)
>
> Bert did say he had a patch, and I also would be interested in seeing
> it. However, this late in the 1.6 release cycle, somebody could swoop
I have a patch that removes all locking (I attached that to issue #3369 in
our issue tracker), but this patch is certainly not release ready as it will
eat real world working copies.
Some kind of locking/synchronization inside the working is really needed.
Just making it global, moving it outside the working copy, etc.. will break
working copies (or at least all working copies shared between users).
I was working on a usable patch that should give a huge performance increase
by using a smarter lock using less files, but this patch is not ready at
this time. (And then, last Friday I ate something that I shouldn't have...
And spend a few days in bed to feel better... :( )
And the current status is 1.6.x branched yesterday, so I don't think a patch
to the old WC will see any real usage anyway. Changing the locking algorithm
requires a working copy format upgrade and there is no between 1.6 and 1.7.
> The same problem which Bert claims to fix in his patch will be fixed
> to a greater degree in a more robust way as part of WC-NG, due in
> 1.7. It's *that* work for which I'd welcome patches (and testers, and
> early adopters, etc).
*nod*
The 1.7 upgrade contains this improvement and many more improvements, by
centralizing all working copy storage. Retrieving what to update will only
require reading this centralized metadata, which should be much faster than
just using smarter locks.
For now, you should use subversion on filesystems that are really fast in
creating small files (E.g. ext3). The actual throughput of a disk on writing
a single file doesn't matter for the administrative area handling of
subversion...
(See http://www.t2-project.org/zine/1/ for some performance overview of the
common linux filesystems)
The 'Creating 100000 files with a single invocation of touch' test is
exactly the file system usage of the locking step Subversion uses right now.
Many filesystems are optimized for disk access and throughput within a file
(like random access on a database, streaming access for audio/video,
etc.)... Centralizing our metadata will increase performance a lot for
systems optimized this way.
For some reason the disk io performance is not checked in this 'filesystem
benchmark'... (The largest file tested is 512 Kbyte, while current hard
disks have caches of several Megabytes)
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1178370
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-17 14:36:28 CET