[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-17 09:36:20 CET

Greg Hudson wrote:
> On Thu, 2007-03-15 at 13:12 -0400, John Szakmeister wrote:
>> 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.
>
> This is a little nitpicky, but if Explorer is taking a long time to
> display a directory, there's a good chance it is spending most of its
> time doing UI operations (composing widgets), not FS operations.

Oh, it does all sorts of file system stuff. It's an incredibly bad
tool.

> That doesn't change your overall point--that we should pick a shard size
> which makes browsing into an svn backend acceptably fast under Explorer.
> But realize that we're now tying the tuning of the svn architecture to
> the performance of particular GUI tools, not to particular filesystems.

I should of given full disclosure. I actually tested using a python
script to create files and walk directory entries (and also one that
used ls... even under Windows). The performance of NTFS was
considerably worse than other common unix/mac filesystems, by an order
of magnitude (you could fit 10x or more files in the same directory as
NTFS before seeing the same delay in obtaining the file list). Throwing
Explorer in the mix made it *considerably* worse. But I focused on
Explorer more than I should have.

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 17 09:36:51 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.