possible win32 fsfs performance

["JS.staff" <js...@ecclescollege.ac.uk>]

If the number of small revision files proves a problem in win32 fsfs, have you thought about using a system like .jar in Java? (for v old rev files)
 
Having multiple directories with x,000 files in each would be ok, but it would be more space-efficient to collect them up into bigger chunks.
 
John

Re: possible win32 fsfs performance

[Kevin Puetz <pu...@puetzk.org>]

JS.staff wrote:

> If the number of small revision files proves a problem in win32 fsfs, have
> you thought about using a system like .jar in Java? (for v old rev files)
>  
> Having multiple directories with x,000 files in each would be ok, but it
> would be more space-efficient to collect them up into bigger chunks.
>  
> John

JAR files are terrible for read-write performance (as you have to keep
rearranging the archive. They make a great way to store lots of read-only
files, but not a good way to store a growing repository.

Besides, chunking like this would require that chunked-fsfs have all the
internal locking facilities that bdb has, to let multiple programs update
it. Which would mean you'd need write access to the repo to do checkouts,
and it would be possible to wedge it if a client crashed, would need
special tools to get a consistent backup, etc. We've aleady got one backend
that chunks things into fewer, bigger files, and has made these tradeoffs
in administrative complexity.

fsfs lets subversion take advantage of the simpler solutions possible if we
have a filesystem that doesn't suck (tm).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org