Thanks Mark for the deep answer.
Regarding your question:
We are using Linux server, running apache 2.2 (over http, without SSL).
The problem occurs on Windows clients over the LAN (mostly), or when WFH with VPN.
Do you think something changed in 1.5 ?
We never found such issue in 1.4, and the repository size was not changed since them.
Thanks, Ido
-----Original Message-----
From: M. Z. [mailto:Ziggyesque_at_hotmail.com]
Sent: Friday, December 12, 2008 8:57 PM
To: users_at_tortoisesvn.tigris.org
Subject: Re: Tortoise (1.5.5) commit failed on large commit
It's not specified which protocol is being used to access the server,
file: or
svn: or http:, and whether it's a LAN or Internet access, so the
following
may not apply. I'm assuming the server is being accessed as a C: or
LAN remap to R: type reference.
One possibility, I believe, where the "DELETE PEND" is coming from is
that
the tempfile.tmp is being moved, via a rename, to the server. Since
another
directory is involved the rename is probably performing a non-atomic
mark-for-delete/copy/delete sequence as a single I/O transaction, but
the
disk cache hasn't flushed file.svn-temp from the copy so it can
complete
the delete of tempfile.tmp before the process scheduler has
reactivated
the thread and it has gotten to where it wants re-create
tempfile.tmp.
In other words the server is not reacting fast enough so that there is
enough
time on the client's side to keep the I/O request queue from stacking
requests up asynchrously. The CLOSE reporting success indicates it
successfully got added to the cache's queue, not that the drive is
actually in a state where the directory index was flushed so that the
re-create can succeed.
If this is the case, it probably indicates a latent bug in one of the
drivers on
the systems, either in the file system driver, the disk or LAN driver,
or in
the OpenFile function that is missing a wait_for_flush on DELETE_PEND
so
the race condition doesn't occur.
As a workaround, in the TSVN code, an explicit Flush call after each
Close of
tempfile.tmp should suspend the thread long enough for the queues to
clear.
I suspect the disk cache delaying flushing is also the reason for the
icon
overlays not updating in a timely manner on some machines where it
does
on others, compunded by the extra I/O requests TSVNCache places on
the queue when it's used.
Without changing the code, you can try explicitly limiting the disk
cache size
so flushes occur with higher frequency due to cache collisions forcing
them.
It may cause some disk thrashing, but the overall responsiveness
should
improve.
Just a thought, as there's insufficient info it couldn't be something
else,
Mark
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=984162
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2008-12-14 21:52:11 CET