On Wed, Jun 25, 2008 at 12:27, Arturo 'Buanzo' Busleiman
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> Replying and forwarding. Sorry I don't edit, it's for the sake of
> completeness. I'll follow regular
> quoting etiquette from now on. My reply at the bottom, this time.
> Simon Large wrote:
> | 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).
> |> repository is on an
> |> external iSCSI SAN disk, mounted on /srv/svn. (The SAN and LAN networks
> |> 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
> |> attempted to browse the
> |> repository, vmware shouts an "I/O error" on the SAN iSCSI device. From
> |> 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,
> |> 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
> |> 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
> |> 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
> |> 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
> |> new virtual partition...
> |> restarted svn on that new mount point... and tortoisesvn works. no
> |> Anyone has ANY idea why it might be falling? May I have hit a bug for
> |> 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.
> No, it shouldn't, but it does happen.
> tortoisesvn + data on SAN disk = crash
> subversion + data on SAN disk = NO crash
> subversion + data on vmdk disk = NO crash
> tortoisesvn + data on vmdk disk = NO crash
> We have two variables (client and location of data). I'm attempting to
> figure out where the issue
> might be. Maybe it's a vmware bug, I don't know, but I rather start the
> bug-catching with tortoise
> and svn.
> | Try asking on the subversion users list (users <at>
> | subversion.tigris.org).
> Done, subscribed and CCed.
> | BTW did you use 1.5.0 subversion Windows binaries for your comparative
> Yes, in Windows.
Are you sure? You have to run
to make sure that the 1.5 client was actually used and not an older
one still in PATH.
Also, from where did you get the 1.5 CL binaries?
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-26 20:13:41 CEST