Glad you found it... Virus scanners do often use a driver filter to
catch
file ops, so I was probably on the right track. This might be
something
you want to report to McAfee as a bug in their driver.
Mark
On Dec 18, 5:11 am, Ido Strahovsky <ido.strahov..._at_intel.com> wrote:
> It looks like we found the root cause.
> There is conflict with MacAfee (version 8.5) that cause to large commit to fail.
> When we define the working copy, or even just the .svn folders as "excluded" for MacAfee scan, the problem is solved.
>
> At may be just workaround for now, but at least we know how to solve these errors.
>
> Thanks all for the help,
> Ido
>
>
>
> -----Original Message-----
> From: M. Z. [mailto:Ziggyes..._at_hotmail.com]
> Sent: Wednesday, December 17, 2008 6:17 PM
> To: us..._at_tortoisesvn.tigris.org
> Subject: Re: Tortoise (1.5.5) commit failed on large commit
>
> 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&dsMess...
>
> To unsubscribe from this discussion, e-mail: [users-unsubscr..._at_tortoisesvn.tigris.org].
> ---------------------------------------------------------------------
> 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=987305
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2008-12-19 10:37:30 CET