On Dienstag, 15. April 2008, Harvey, Edward wrote:
> > I agree wholeheartedly with what John wrote in his reply. Scanning a
> > disk can be done a lot faster than we're currently doing; centralized
> > metadata helps, but there are obviously other tricks, too -- just as an
> > example, look at how quickly Google Picasa can scan your whole disk for
> > images!
>
> I challenge the idea that scanning the whole tree could possibly ever be
> "fast."
If seek time can be eliminated, by using a central data storage and going
through the inodes in "correct" order, you can save *much* time.
Ever tried FSVS? I'll quote my previous email; for 22147 (known) entries (ie.
that exist in the repository and are just checked for changes) on *cold*
caches:
# time fsvs st > /dev/null
real 0m6.000s
user 0m0.240s
sys 0m0.372s
Not bad, no?
That's on Linux, ext3.
> Yes, if you do it once and repeat it, then you're benefitting from
> the cache on the 2nd run - For my users that makes the difference between
> 10 minutes and 30 seconds. But they're only going to svn up (or whatever)
> ... once, twice, three times a day ...
How often do you do "svn st"?
> And the system is doing actual work
> in parallel. So they never benefit from the cache. Every time they scan
> the tree, it takes 10 minutes.
Well, if you always purge your OS's cache, you'll have to go to the harddisk
to get the information ...
> I considered seriously, writing a cron script to tar all the .svn dirs into
> /dev/null, and stat the whole working copy of every user, ever 5 minutes.
> Just to keep that info in cache. But I finally decided that was stupid
> enough to abandon it.
tar is "intelligent" enough to not bother with the data if it sees that it
writes to /dev/null - you'd have to use /dev/zero instead.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-15 15:45:38 CEST