<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Regarding ZFS: is that available for Linux now? I lost a bit track here.<br></blockquote><div><br></div><div>Yes.</div><div><br></div><div><a href="http://zfsonlinux.org/">http://zfsonlinux.org/</a><br></div><div><br></div><div>I would say its ready for production now. Intel are about to start supporting it under Lustre in the next couple of months and they are typically careful about such things.</div><div><br></div><div>Cheers,</div><div><br></div><div>Andrew</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
All the best from London<br>
<br>
Jörg<br>
<div><div class="h5"><br>
On Sonntag 21 September 2014 you wrote:<br>
> Hi Jörg,<br>
><br>
> Sounds like a "typical" but very uncommon silent data corruption problem.<br>
> If you have another copy of the data, compare to that? If you don't have<br>
> another copy, accept the fact that some of your data maybe got silently<br>
> corrupted.<br>
><br>
> Most RAID controllers do periodic "scrubbing"; was your Infortrend doing<br>
> that?<br>
><br>
> For the new system, consider using ZFS pointed at plain disks, as it may<br>
> have more layers of checksums compared to your current system.<br>
><br>
> Regards,<br>
> Alex<br>
><br>
> On Sunday, September 21, 2014, 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>
</div></div>> > email: <a href="mailto:j.sassmannshausen@ucl.ac.uk">j.sassmannshausen@ucl.ac.uk</a> <javascript:;><br>
<div class=""><div class="h5">> > 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>
--<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></div>