I keep hearing this "many small files" argument. Has anyone looked into
this? I was involved in a project a few years back (not scc related)
that did indeed have many small files in an NTFS tree, and we never had
any performance issues when we compared the Linux/Windows versions (of
course, maybe both were equally slow...).
On *really* small files NTFS should be quite good, as the data goes
directly in the MFT -- are we talking medium files and lots of
simultaneous accesses, or what?
--Tim
Peter N. Lundblad wrote:
>On Tue, 26 Apr 2005, François Beausoleil wrote:
>
>
>
>>Ludvig Strigeus said the following on 2005-04-26 08:52:
>>
>>
>>>A better solution is:
>>> * check if timestamp & size matches, if they do, mark the file as not
>>>modified
>>> * compute the SHA1 hash of the file and compare it to the entries file,
>>>if equal, mark the file as not modified, otherwise, the file has been
>>>modified.
>>>
>>>
>>And that is exactly the algorithm SVN utilizes (except it's using MD5
>>instead of SHA1). If Subversion reads all files, then your timestamps
>>might be off. There's an operation you can do that will correct the
>>timestamps, but I can't remember the command to use.
>>
>>
>>
>svn cleanup, but that's in 1.2.
>
>Also, note that svn has to check the property files, which also takes
>time. Performance on Windows isn't as good as we'd like because of svn
>using many small files.
>
>Regards,
>//Peter
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
Received on Tue Apr 26 22:53:54 2005