Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

We have cloned the disk with vmkfstools and tried again. Unfortunately, still getting the "segmentation fault" error.

Anything else we could do/try?
What VMWare version are you using?

Yes, there shouldn't be any cross-posting. This wasn't meant to happen.

We do consider your suggestions seriously, therefore we only ask question about the errors which we observe.
In the end, we are happy, when you can provide support in order to make XSIDiff work in client/server mode.

As posted in the other thread: the network looks fine. Copied 120GB file through terminal (cp) to NFS share, from multiple host. We are using Meraki, CISCO and HP-E (as backup) devices. The Switches don't report any lost packet or other issues. No other issues with the network whatsoever. No users reported issues with the network. All other applications work fine.
What other things could be verified in order to see, if there is an issue with the network?

Generally ,'Segmentation fault' is a memory 'access violation' caused/raised by XSDiff.
'Error writing struct info to SOCKET' is related to the socket, which was created by XSIDiff.

We cannot debug the socket, as it is created by XSDiff, but it looks like an overflow.

XSIDiff man page

My take on this situation: we shouldn't quarrel, we should find a solution.

Well, you haven't provided a solution or support on how to make it run as advertised.

You mentioned security standards, that's why you don't load a TCP server.
On the other hand, rsync is loaded that way as client/server. This seems contradictory to us.

We still can't get the tools working (please see other post) as advertised. How to conclude? Should we return the license?

Can this error be ignored?
As long as the packets are re-transmitted and no data is lost, I wouldn't bother too much, but still like to get rid of it.

These are the commands I use:

Server
"./xsidiff --source=ServerIP:33 --target=/vmfs/volumes/datastore1/XXX/XXX-flat.vmdk"

Client
"./xsidiff --source=/vmfs/volumes/datastore1/XXX/XXX-flat.vmdk --target= ServerIP:33"

I guess, nothing is missed with those commands?

Agree, we should stay with the facts: if the CPU is the bottleneck, the numbers should be different.
Please be aware as well, that I haven't written "bad implementation" nor did I expressed this in any other way.

It's advertised, that XSDiff is outperforming rsync. I can reproduce this, if XSDiff is run in client/server mode. The CPUs stay almost in IDLE.
However, XSDiff is slow -even slower than rsync- when used as backup-prog option in XSIBackup, as it is run through a SSH tunnel.

There is a better approach/algorithm in order to achieve, what is advertised. You actually already do this with rsync.

The relevant lines in the script -please correct if wrong- might be this

[XSDIFF]
RSYNCOUT=$( ("$PWD/bin/xsidiff" --source="${flatorigin}" --target=stdout "$XSIDIFFSILENT" | eval ssh "$SSHOPTS" -p$baksrvport ${defremusr}@$baksrvaddr "\"${RMXSIDFPATH//\ /\\ }\" --source=stdin --target=\"${flattarget//\ /\\ }\"" >&16) 2>&1 )

and this

[RSYNC]
RSYNCOUT=$( ("$PWD/bin/xsibackup-rsync" -rlpDv --progress ${rsyncoptions} --whole-file --sparse --rsh="ssh $SSHOPTS -p$baksrvport" --rsync-path="${RMRSYNCPATH}" "$flatorigin" ${defremusr}@$baksrvaddr:"${flattarget}" >&16) 2>&1 )

The rsync command line gives a blueprint (--rsh (-e) option ) of the steps of how to run the XSIDiff command in the very fast client/server mode:

// 1) fire up XSIDiff as server on remote host
ssh name@host "./xsidiff --source=server_IP:33 --target=[file2]"

// 2) run XSIDiff to do the copy/transfer
./xsidiff --source=[file1] --target=server_IP:33

// 3) kill XSIDiff server on remote host
ssh name@host "kill $xsidiff_PID"

What is your thought?

I have used esxtop on both hosts.

Generally, the source host is a C2750 Avoton (8-core), the target host is a C3558 Denverton (4-core).

With just XSIDiff executing in client/server mode, the CPU load average on the source is about 0.14. There are as well 4 VMs running (IDLE). So, I would say hardly no load. This wasn't an issue anyway.

With 'XSIBackup -backup-prog XSIDiff' the CPU load average is about 0.20, the PCPU AVG between 25% and 35%. I've observed a short peak of 68% of one single core, which is probably related to some VM activity.
The target host has a CPU load average of 0.27 and a PCPU AVG of about 30%

The SSH Process takes around 80% (%USED) on the source and around 50% (%USED) on the target. Not sure if this yet is a sign of overload?

I'll have a look at XSIBackup-Datacenter, but would like to get XSIBackup & XSIDiff well performing, as I just bought the license...