<div dir="ltr">Hi,<div><br></div><div>memtest86+ from <a href="http://memtest.org">memtest.org</a> will detect most common memory issues - though it may need to run for a couple of days. Since everything used to work fine, maybe it is a good idea to focus on the new hardware. It is not unusual for brand new equipment to be faulty.</div><div><br></div><div>Cheers,</div><div><br></div><div>Dimitris</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 11:17 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">Hi Dimitris<br>
<br>
thanks for the feedback.<br>
<br>
I can rule out the front end as I was using that with a different disc array<br>
without any problems. So I am somewhat confident that the front end and the<br>
controller are ok.<br>
<br>
As for the disc array: I got a new controller here so one would assume that<br>
one is working ok. I am in touch with the manufacturer to see if there is a<br>
problem with that.<br>
<br>
I done some stress testing in terms of copying the files over from the old<br>
server to the new server and I did not see any problems here when I was using<br>
a test board, i.e. a different front end with a different controller.<br>
<br>
Having said that: I cannot really rule out that the controller I am currently<br>
using might have a problem as: it is a dual controller (two scsi connections)<br>
and one of the boxes which was connected there had a slower transfer rate.<br>
What I do not know is whether then the controller is stepping down and hence<br>
any problems will be masked due to the slower transfer rate.<br>
<br>
Unfortunately, like so often, the hardware is in use and needed so I cannot<br>
take it offline too often and then hamper people's work.<br>
<br>
Talking about memtest: which one do you suggest? memtest or memtester? I have<br>
heard different opinions about them.<br>
<br>
All the best from a mild London<br>
<span class="HOEnZb"><font color="#888888"><br>
Jörg<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Donnerstag 02 Oktober 2014 you wrote:<br>
> Hello,<br>
><br>
> RAM somewhere could also be faulty. Have a look at the logs for any ECC<br>
> errors (both system memory and RAID controller) and memtest the boxes<br>
> involved for a couple of days. I would suggest some stress testing of the<br>
> new server if not done already.<br>
><br>
> Best regards,<br>
><br>
> Dimitris<br>
><br>
><br>
><br>
> On Sun, Sep 21, 2014 at 3:22 PM, Jörg Saßmannshausen <<br>
><br>
> <a href="mailto:j.sassmannshausen@ucl.ac.uk">j.sassmannshausen@ucl.ac.uk</a>> wrote:<br>
> > Dear all,<br>
> ><br>
> > I got a rather strange problem with one of my file servers which I<br>
> > recently 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<br>
> > temporary disc<br>
> > storage space using this rsync command:<br>
> ><br>
> > rsync -vrltH -pgo --stats -D --numeric-ids -x oldserver:foo<br>
> > 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<br>
> > problem later and the user is loosing data. This time around a rather<br>
> > large file (around 16 GB) the md5sum failed after I moved the files from<br>
> > 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<br>
> > from the<br>
> > old file space. Strangely enough, rsync does not sync the file again so I<br>
> > 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,<br>
> > i.e. the<br>
> > md5sum is correct.<br>
> > As it is a tar.gz file, I simply decided to decompress the original file<br>
> > on the<br>
> > different file server. That worked. The file where the md5sum is wrong<br>
> > did not<br>
> > decompress on the different file server but crashed with an error message<br>
> > 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<br>
> > it.<br>
> > This box is connected via scsi to a frontend server which exports the<br>
> > file space via iscsi. The backend for that, i.e. the one the user is<br>
> > accessing is<br>
> > on a different physical machine and it is a XEN guest. The reason behind<br>
> > 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<br>
> > SATA capeabilities but still got scsi connection to the frontend. The<br>
> > 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<br>
> > the 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<br>
> > I have<br>
> > copied over some files (again using the rsync command above) a few files<br>
> > 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<br>
> > some<br>
> > binary files there seems to be a problem. However, I am not sure there to<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><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>
</div></div><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>