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

Re: Sharded FSFS repositories - summary

From: John Szakmeister <john_at_szakmeister.net>
Date: 2007-03-15 18:12:52 CET

----- "John Peacock" <jpeacock@rowman.com> wrote:
> John Szakmeister wrote:
> > I actually did this for NTFS (under VMware) using a python script.
> I
> > posted my results earlier in this thread:
> > http://svn.haxx.se/dev/archive-2007-03/0134.shtml
> >
> > FWIW, NTFS scales very badly.
> But performance from Explorer is not typical of performance for
> Subversion itself (i.e. M$loth made stupid decisions in the design of
> Explorer - e.g. scan every single file before returning). A much better
> test would be a small script which would create many files and then time
> opening and reading those files both sequentially and "randomly" to see
> whether the underlying filesystem scaled well under different directory
> layouts.

I think we're talking about two different things. I realize that the performance of Explorer isn't the same as Subversion's... because SVN will know the path it wants to open. But as Ph. Marek (I believe it was him), when things fail, an admin will want to look at the backend. I think taking 15 seconds to show a directory listing is unacceptable, and you can be certain that Windows folk will be using Explorer.

I wasn't necessarily trying to say those numbers are reflective of the performance that SVN would have regarding sharding. Only that NTFS doesn't scale well, so that's probably the file system we need to base most of our decisions around.

I hope that clears things up a little.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 15 18:13:11 2007

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.