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
On Dec 11, 9:44 am, Ido Strahovsky <ido.strahov..._at_intel.com> wrote:
> Can you please specify what are the temp file that may be deleted ?
> Where are they store ?
> Also, if we break bug commit (which fail) to multiple smaller commit, we succeed to commit, so I am not sure it relate to the temp files.
>
> Thanks, Ido
>
>
>
>
>
> -----Original Message-----
> From: Stefan Kueng [mailto:tortoise..._at_gmail.com]
> Sent: Wednesday, December 10, 2008 6:43 PM
> To: us..._at_tortoisesvn.tigris.org
> Subject: Re: Tortoise (1.5.5) commit failed on large commit
>
> Ido Strahovsky wrote:
> > Hi,
>
> > After upgrading to 1.5.5 we had a lot of commit which fails with the
> > error “svn Can't open '.svn/tmp/tempfile.tmp'”.
>
> > We investigate and here is summary of the conclusions:
>
> > 1. It did not happen on 1.4 (server and clients).
>
> > 2. Seems it depends on both amount of files and their size. If the
> > number of files which are committed is more 50 + the commit will fail.
>
> > 3. The problem is reproducible on multiple clients.
>
> > 4. It happened also when the antivirus and firewall were disabled.
>
> > 5. We ran FileMon, see the result below.
>
> The "buffer overflow" you see is not an error but completely normal:http://blogs.technet.com/markrussinovich/archive/2005/05/17/buffer-ov...
>
> But the "DELETE PEND" indicates that something deleted the file which
> should not have happened. Do you have a cleanup tool running which
> cleans temp files automatically?
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
> ------------------------------------------------------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=983507
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2008-12-12 20:03:40 CET