John Peacock wrote:
> Keven Ring wrote:
>> solo turn wrote:
>>> since 0.33 using linux as client (i just tried with reiserfs) is
>>> very fast (10 times as fast as windows),
>> Still, the times between CVS and an SVN server shouldn't be *THAT*
>> far off. I can understand that the HTTP would be a bit slower due to
>> the extra chattiness of it, but still not 10x slower!
> Solo was saying that Windows client was 10x slower than Unix client,
> which I can certainly find plausible. NTFS is not well suited for
> lots of small files (with default settings); changing the parameters
> can yield suprising increases in performance.
> One feature of NTFS is that the block size is also the size of a node
> in the directory information structure, and that if the file is
> actually small enough, it will be stored in the directory structure
> instead of as a seperate file in the filesystem. This method can lead
> to more slack space (allocated but unused space on the drive), but
> storage is so cheap, I would rather waste space than time. I used an
> 8k block size for an NTFS mail application and noticed a definite
> performance boost.
> OTOH, this has no bearing on your issue, since you are using Fedora
> Core 1. What would be useful is to find out what filesystem you are
> using on the partition where your WC is loaded. For example, if you
> are using a Samba share or NFS, there are known performance penalties
> for storing your files on a networked share.
The working copy is on a local ext3 partition.
The CVS repository on the sun box [see previous emails] looks like an
NFS drive [I thought it was a local drive]
The Subversion repository on the dual-xeon Fedora Core 1 box is a
locally mounted ext3 partition.
For all tests, the same, fedora core 1 machine was used to import and
checkout files. All files were imported and checked out from a locally
mounted ext3 partition.
HTH. Let me know if there is any other helpful information.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Apr 19 23:27:05 2004