(First, let me mention I realize it is not advised to keep a working copy
on a NAS.)
We noticed during a network trace of updating a working copy that was
stored on a NAS,
that there were a lot of small 512 byte reads and writes to the network.
Curiously, I then fired up the sysinternals filemon utility and had it
monitor
read and write access for svn.exe during a working copy update of one file
on my local
pc. It showed a large number of these small 512 byte file accesses.
For example:
READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
Offset: 0 Length: 512
WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
Offset: 0 Length: 512
READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
Offset: 512 Length: 512
WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
Offset: 512 Length: 512
READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
Offset: 1024 Length: 512
WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
Offset: 1024 Length: 512
READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
Offset: 1536 Length: 512
WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
Offset: 1536 Length: 512
READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
Offset: 2048 Length: 512
WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
Offset: 2048 Length: 512
READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
Offset: 2560 Length: 512
WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
Offset: 2560 Length: 512
READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
Offset: 3072 Length: 512
WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
Offset: 3072 Length: 512
...
READ C:\docs\.svn\tmp\text-base\svn-book.pdf.svn-base SUCCESS
Offset: 1351168 Length: 512
WRITE C:\docs\.svn\tmp\svn-book.pdf.tmp.tmp SUCCESS
Offset: 1351168 Length: 512
A few things I noticed:
1) A file is named .tmp.tmp and stored in a "tmp" directory.
Isn't that a little redundant?
2) It appears to be reading the text-base file 512 bytes at a time
and then writing the (same???) 512 bytes out to the temp file.
Isn't that buffer size fairly small and inefficient?
Probably not noticeable on a local disk, but is quite an
impact when on a high latency network where the 512 byte packets
are acknowledged before the next one is transmitted.
I'm hoping someone familiar with the working copy code can comment on
this behavior. I'd be willing to dig into this a little deeper, provided
someone that knows the code better doesn't give a valid reason for the
small buffer sizes. (I'll admit I am completely ignorant of the
working copy code, but I'm always willing to learn.)
Command that was run:
svn up -r HEAD docs\svn-book.pdf
(After I had run an "svn up -r PREV docs\svn-book.pdf")
Here is the windows client info (The standard Collabnet windows one):
C:\>svn --version
svn, version 1.4.3 (r23084)
compiled Jan 18 2007, 07:47:40
Server is running Subversion 1.4.5 on Windows 2003.
Thanks!
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 13 23:59:22 2007