<div dir="ltr">Hello,<div><br></div><div>RAM somewhere could also be faulty. Have a look at the logs for any ECC errors (both system memory and RAID controller) and memtest the boxes involved for a couple of days. I would suggest some stress testing of the new server if not done already.</div><div><br></div><div>Best regards,</div><div><br></div><div>Dimitris</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 21, 2014 at 3:22 PM, Jörg Saßmannshausen <span dir="ltr"><<a href="mailto:j.sassmannshausen@ucl.ac.uk" target="_blank">j.sassmannshausen@ucl.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
I got a rather strange problem with one of my file servers which I recently<br>
have upgraded in order to accommodate more disc space.<br>
<br>
The problem: I have copies the files from the old file space to a temporary disc<br>
storage space using this rsync command:<br>
<br>
rsync -vrltH -pgo --stats -D --numeric-ids -x oldserver:foo  tempspace:baa<br>
<br>
I am doing this now for some years and never had any problems.<br>
<br>
As always, I am running md5sum afterwards to be sure ther is not a problem<br>
later and the user is loosing data. This time around a rather large file<br>
(around 16 GB) the md5sum failed after I moved the files from the temp space<br>
back to the new destination using the same command as above.<br>
<br>
Having still access to the old file space, I decided to move this file from the<br>
old file space. Strangely enough, rsync does not sync the file again so I had to<br>
delete the file. Even after deleting the file and re-sync it from the old<br>
source, the md5sum is wrong.<br>
<br>
Copying the file to a different file space did not cause these problem, i.e. the<br>
md5sum is correct.<br>
As it is a tar.gz file, I simply decided to decompress the original file on the<br>
different file server. That worked. The file where the md5sum is wrong did not<br>
decompress on the different file server but crashed with an error message when I<br>
executed gunzip. So the file is broken.<br>
<br>
The setup:<br>
<br>
Originally I was using an old Infortrand box which had old PATA discs in it.<br>
This box is connected via scsi to a frontend server which exports the file<br>
space via iscsi. The backend for that, i.e. the one the user is accessing is<br>
on a different physical machine and it is a XEN guest. The reason behind that<br>
setting is as the frontend is acting as a backup server and I don't want<br>
people to have access to it.<br>
I then exchanged the Infortrend box with a more recent model which got SATA<br>
capeabilities but still got scsi connection to the frontend. The frontend is<br>
the same. I got a new controller for that box as the old one was broken.<br>
There is no changes in the backend, that is still the same XEN guest on the<br>
same hardware.<br>
<br>
What I cannot work out is why the old Infortrend box does not have any<br>
problems with the new file, the newer one has a problem here. Also, when I have<br>
copied over some files (again using the rsync command above) a few files did not<br>
copy correctly (again md5sum) in the first instance but done so later.<br>
<br>
I find that highly alarming as that means that at least for larger and/or some<br>
binary files there seems to be a problem. However, I am not sure there to look<br>
at it as I am out of ideas.<br>
<br>
Could it be there is a problem with the 'new' controller?<br>
In all cases I was using ext4 as a file system and I did not have any problems<br>
with that.<br>
<br>
Anybody got some sentiments here?<br>
<br>
All the best from a sunny London<br>
<br>
Jörg<br>
<br>
P.S. To make things worse I am off on a work related trip from Monday onwards<br>
and I am working on that problem since Friday evening.<br>
<br>
<br>
<br>
--<br>
*************************************************************<br>
Dr. Jörg Saßmannshausen, MRSC<br>
University College London<br>
Department of Chemistry<br>
Gordon Street<br>
London<br>
WC1H 0AJ<br>
<br>
email: <a href="mailto:j.sassmannshausen@ucl.ac.uk">j.sassmannshausen@ucl.ac.uk</a><br>
web: <a href="http://sassy.formativ.net" target="_blank">http://sassy.formativ.net</a><br>
<br>
Please avoid sending me Word or PowerPoint attachments.<br>
See <a href="http://www.gnu.org/philosophy/no-word-attachments.html" target="_blank">http://www.gnu.org/philosophy/no-word-attachments.html</a><br>
<br>_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
<br></blockquote></div><br></div>