You are not logged in.
when I run XSIDiff, I get below error messages (around 140).
Any idea how to fix it?
(c) XSIDiff 184.108.40.206 licensed:
Meta-data available, zero aware copy
Reading from file /vmfs/volumes/datastore1/XXX/XXX-flat.vmdk
Writing to socket, block size 16384
Connected to socket 5
Error writing struct info to SOCKET 5Set input file offset to 0 bytes
Error writing struct offset_out position 0
Error writing struct offset_out position 19922944
Error writing struct offset_out position 40894464
Error writing struct offset_out position 103809024
Error writing struct offset_out position 39596326912
Error writing struct offset_out position 40133197824
Error writing struct offset_out position 40670068736
That seems to be a simple broken pipe
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:
"./xsidiff --source=ServerIP:33 --target=/vmfs/volumes/datastore1/XXX/XXX-flat.vmdk"
"./xsidiff --source=/vmfs/volumes/datastore1/XXX/XXX-flat.vmdk --target= ServerIP:33"
I guess, nothing is missed with those commands?
I would not ignore it for obvious reasons.
XSIDiff, despite its name, is not a differential tool, it just copies data as is. It is zero aware, but it is only differential when used from within Onediff.
When you use it you are copying all data each time. If you get a broken pipe condition in the middle of a copy, restart the job.
Restarting the job doesn't seem to be right solution: The error messages are literally flushed in one go, then the copy-process starts. This is why you could think, the tool is recovering from those errors.
Now, this is the situation, how we see it:
We have tried a 10GB file and it worked fine.
We bought the license to have XSIDiff/XSIBackup working with larger files.
With a file of around 40GB we get "Error writing struct".
We now tried it on a 120GB file and we get "Segmentation fault".
The instructions "XSIDiff man page" were followed and it doesn't work. No other documents with any requirements or limitations were provided.
XSIDiff is not sold alone, it is a binary bundled with XSIBACKUP-PRO, it works when called from XSIBACKUP-PRO. You didn't buy XSIDiff as we don't sell it. Use XSIBACKUP-PRO as described in the program's documentation.
Correct. I had to purchase XSIBACKUP-PRO in order to get the XSIDiff license. As it is not a product which you can split, I have to return the entirety.
We do follow the documentation in terms of intended use and syntax:
"(c)XSIBackup: using backup programs" (Intention)
... (c) XSIDiff is a standalone binary that requires its own license key and that may be used separately to copy files manually between datastores, different ESXi hosts or from an ESXi host to a Linux system. ...
"XSIDiff man page" (Syntax)
IP Server :
./xsidiff --source=10.0.0.1:33 --target=[file2]
IP Client :
./xsidiff --source=[file1] --target=10.0.0.1:33
Unfortunately, this returns a "Segmentation fault"
We have tried your command in the very same scenario with big files: 50GB and 100GB and we don't get any write error. Debug your network and make sure that it is working properly. XSIDiff will throw those errors when it can't write data to the socket for some reason, the most common one is some network problem.
Copied 120GB file through terminal (cp) to NFS share, from multiple host. Network works properly. The Switch doesn't report any lost packet or other issues. No issues with the network whatsoever.
'Segmentation fault' is a memory 'access violation'.
'Error writing struct info to SOCKET' is related to the socket, which was created by XSIDiff.
Yes, looks like an issue while data written into the _local_ socket. What are the socket options, while creation?
The offset positions don't look random. What are buffer-/cache-size, XSIDiff is working with?
A variable overflow would makes sense, as it explains as well the 'Segmentation Fault' error.
You are duplicating your posts, that won't get you more support.
Since the moment that you consider that using an Atom processor should not hurt SSH performance and you are not even open to reconsider your position, I'm afraid there's not much we can do for you.
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.