YQW... It's quite possible something did... There's enough new code
in 1.5 that there could easily be enough of a different execution
path
than was previously that where you hadn't run into a timing problem
before, or yet, it was close enough you're getting it now. I'm more a
user than one of the developers, though, so one of those that's run
the code in conjunction with a profiler could give a better answer.
It could be informative, if you still have a machine with 1.4 or can
reinstall it, to do the same type of FileMon run with that and
compare the average intervals between the file operations, whether
they're significantly shorter or longer a time between, especially
around the point where 1.5 fails. You could also track network
packets to see if those are stacking up around the failure point.
If all the clients are using the same network card, you might want
to see if there's a more recent driver update for it, as it could be
the bottleneck. Another thing you could try is enabling svn://
access also and see if that helps, as it's possible something in
the WebDAV module is contributing also.
Good luck,
Mark
On Dec 14, 3:50 pm, Ido Strahovsky <ido.strahov..._at_intel.com> wrote:
> 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:Ziggyes..._at_hotmail.com]
> Sent: Friday, December 12, 2008 8:57 PM
> To: us..._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&dsMess...
>
> To unsubscribe from this discussion, e-mail: [users-unsubscr..._at_tortoisesvn.tigris.org].- Hide quoted text -
>
> - Show quoted text -
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=985851
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2008-12-17 17:18:10 CET