[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tortoise locks up, cmdline svn does not

From: Simon Large <simon.tortoisesvn_at_googlemail.com>
Date: Wed, 25 Jun 2008 09:39:29 +0100

2008/6/25 Arturo 'Buanzo' Busleiman <buanzo_at_buanzo.com.ar>:
> Hi group!
>
> I've found a weird behaviour. First, let me describe my platform:
>
> * An ubuntu server 64bit virtual machine in Vmware Server (Ubuntu Host). The
> repository is on an
> external iSCSI SAN disk, mounted on /srv/svn. (The SAN and LAN networks are
> physically distinct ones).
>
> * Windows clients using tortoisesvn.
>
> This setup has been working without issues at ALL for the past two weeks
> (since it was implemented).
>
> Yesterday night, a developer released a bunch of locks, and the next time he
> attempted to browse the
> repository, vmware shouts an "I/O error" on the SAN iSCSI device. From then
> on, only an "Abort",
> then a reboot can get the svn server up and running.
>
> So, I made a full test of every element involved:
> * SAN disk was OK, I could read/write data without issues. I even ran, from
> within the VM guest, an
> ext2fs -c. No issues.
> * I upgraded all software elements: tortoisesvn, ubuntu guest (except for
> vmware-server, which was
> already 1.0.5 [i know there's 1.0.6, but the changelog shows nothing
> related).
>
> Then I started active testing:
>
> * run "svn checkout svn://127.0.0.1/same_project" using the root shell
> account on the svn server. It
> works, no vmware warning window.
> * run "svn checkout svn://10.100.4.55/same_project". Same as before, but
> using the NIC.
> * run "svn checkout svn://10.100.4.55/same_project" but from another linux
> machine in the network.
> No issues!
> * I asked a windows-workstationed developer to download the command-line
> subversion binaries, and do
> ~ the same checkout from the same windows machine. It WORKS.
>
> I asked them to test tortoise and BANG, vmware warning. The same warning is
> triggered when using
> tortoisesvn from any other windows computer.
>
> I'm think this has to do with some packet size, data transfer,
> tortoisesvn-thing while interacting
> with a SAN disk (which, again, if I access using standard subversion client,
> never crashes).
>
> So, to test that theory, I added a standard virtual disk to the guest (a
> local file on the vm HOST,
> not an iSCSI exported lun), rsynced the data from the SAN partition to the
> new virtual partition...
> restarted svn on that new mount point... and tortoisesvn works. no crashes.
>
> Anyone has ANY idea why it might be falling? May I have hit a bug for this
> kind of scenario? Is
> there any other list I should be cross-posting to? My googling keywords
> involve iscsi, subversion,
> vmware, etc. Nothing interesting appears. So, if you can provide any
> ideas...! :)

Since you're using svn:// the data is accessed using the svn server,
not the client, and no client should be able to crash a server. Try
asking on the subversion users list (users <at>
subversion.tigris.org).

BTW did you use 1.5.0 subversion Windows binaries for your comparative test?

Simon

-- 
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-06-25 10:39:53 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.