-----BEGIN PGP SIGNED MESSAGE-----
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). 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
|> 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.
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
| Try asking on the subversion users list (users <at>
Done, subscribed and CCed.
| BTW did you use 1.5.0 subversion Windows binaries for your comparative test?
Yes, in Windows.
The Linux subversion tests where 1.4.6. (Ubuntu Server 8.04 standard repos).
Should I try upgrading svnserve?
Arturo "Buanzo" Busleiman
Independent Security Consultant - SANS - OISSG
Tired of SPAM? Slow Internet in your office? Ask me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
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 12:28:10 CEST