[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: performance enhancement by working copy svn server

From: Chris Frost <chris_at_frostnet.net>
Date: Tue, 8 Apr 2008 23:35:39 -0700

On Mon, Apr 07, 2008 at 01:09:23PM -0700, Jack Repenning wrote:
> FUSE is a fairly portable (Linux, Mac OS X) basis for such a thing:
> http://fuse.sourceforge.net/
> Chris Frost has worked on serving Subversion working copies out of a FUSE
> volume, in his "scord" project:
> http://scord.sourceforge.net/
> His goal is different from yours: to reduce the disc storage costs of the
> pristine copies. But he's inserted himself into the file system in the right
> spot to do these other things as well.

Fwiw, I see two relevant parts to the speed of the working copy operations
status, diff, etc:
1) read the necessary data from disk
2) traverse the in-memory file system
Part 1 happens to be what I notice most as limiting my svn use. However, it
sounds like only part 2 is a limitation in your situation. (And you could,
of course, aim to improve both parts.)

Routing working copy access through a FUSE file system would definitely be a
way to go. Fwiw, I think the main three limitations to watch out for would be:
- The FUSE API only works on Linux, MacOSX, and BSD
- Serving large data chunks or running many filesystem system calls via
  FUSE incurs a significant increase in the number of kernel-user crossings,
  data copy operations, and kernel file system cache memory used
- Supporting multiple users with a FUSE server instance might be hard

And easier, but still something to think about, is server/os crash recovery.
I suspect you might make it safe on file systems like ext3 in its default
journaling mode, ordered journaling, and not safe on other file systems,
as the working copy library does itself. Fwiw, I have considered augmenting
the underlying working copy representation that scord itself stores, but
each time decided that the benefit didn't justify the synchronization work.
But these issues might work differently for this scenario.

A David mentioned, file notification mechanisms, like at least Linux and OSX
have, would be another route. This would mostly-to-completely avoid the speed,
multi-user, and safety FUSE limitations.

Chris Frost  |  <http://www.frostnet.net/chris/>
PGP: <http://www.frostnet.net/chris/pgpkey.txt>
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-09 08:35:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.