Hi, I have just reboot all the cluster nodes and noticed it is the same node that requires an fsck on boot up. This time the 'damage' repaired did not seem to be as much as previously.
I think I've ruled out dns issues on the Rocks Cluster, so I've provided some details about my configuration. Before I attempt and upgrade to v2.6.2, my question is: Can anyone see anything obviously wrong with the configuration files (attached)? I have attached an archive containing various files described below. After boot up I checked I could ping between the machines. I also ran the test installation steps set out in the quick statrrts guide - all seemed to go fine - the output is in the file: pvfs2-test-installation.log I have attached the pvfs2-client.log files from each on the three machines: pvfs2-client.log.<machine_name> These logs cover the period when I last saw the copy to pvfs2 fail. I have attached the .conf files that were in the frontends' /opt/pvfs2/etc directory. All these files were created by the Rocks Roll, and I've not altered them. Appreciate any suggestions. Regards Mark On 2/20/07, Murali Vilayannur <[EMAIL PROTECTED]> wrote:
Sounds good, Mark. Keep the list posted on how things go. Also provide us with a strace log of where the cp fails, interesting snippets from the kernel logs if any. Please do not hesitate to ask questions. You will hopefully get very prompt answers from someone...:) thanks! Murali On 2/20/07, Mark Van De Vyver <[EMAIL PROTECTED]> wrote: > Hi Murali, > Thank you for your responses - greatly appreciated. > > > > I've tried copying the contents of several DVD's to PVFS2 (1.5.1). > > > The copy completes without any errors reported, and the > > > /tmp/pvfs2-client.log files are empty. > > > The Linux ssytem used is CentOS 4.4, x86_64. > > > I haven't applied any updates. > > > > On an x86_64, largefiles support does not need to be turned on.. so > > this must be a bug elsewhere.. hmm. > > > I'm not sure if the following sheds any light? > The files are typically 1-3GB in size. > I've been progressively re-jigging how I copy these files and now I > see less (but still roughly one per DVD after approx 3 DVD's are > copied) inconsistent copy results. I use cmp to compare each file > after it is copied. > Previously I was copying the whole DVD with `dd` to a tmpfs area, then > I used `cp` to copy from the tmpfs to the pvfs area - this gave me the > iso files I mentioned in another email. > > The current thread refers to the following sequence: > cp --archive /media/cdrom/* /tmpfs/dir > then > cp /tempfs/dir /pvfs/dir > > I've now simplified this this to cp each file directly to PVFS area > from the DVD, then I use cmp to check if it is the same as the > original. I get better results but there are inconssitent results > after about 3-6 DVD's, then PVFS abnormally ends. > I'm going to try and rule out a dns issue on the metaserver/Rocks > frontend, then I will retry, and if things are still amiss I'll > provide pvfs-client.log files and the pvfs config files > > > > > > > To check wether there are errors I run > > > diff -urN /pvfs2/dir /media/cdrom > > > > Alternatively run md5sum and sha1sum on the files. > > These utilities also have a -c option whereby they can check if the > > checksums specified in the input text file matches with what is on > > disk. > > I now use `cmp` to compare each file after it is copied. > > > > I notice that the differences in the binary files are indicated. Some > > > text files that are also on the DVD seem to be copied correctly. > > > I've tested this with about 6 DVD and on three machines and see the > > > same behavior. > > > > Hmm.. I doubt if this is a known regression. Can you upgrade to the > > latest version of pvfs2 (v2.6.2) and see if this is still an issue? > > Hmm, I'll check one last possibility (the dns previously mentioned), > then I'll conpemplate an upgrade. I'm new to this linux/pvfs world > and am scared (terrified) of breaking the current setup - I first > would like to make sure it really is PVFS that is the issue :) > > > Unless an upgrade is impossible, spending time on older releases may > > not be so fruitful unless you have a ready test case to reproduce the > > problem :) > > Sure, if I can't make progress shortly I'll upgrade. > > > If the same problem occurs with HEAD or with 2.6.2, I am sure we can > > quickly work with you on a fix. Do let us know.. > > > > > > > > When copying to a PVFS2 area is diff the appropriate way to inspect if > > > a copy is consistent with the original? > > > > I usually prefer md5sum or sha1sum.. > > > > > Is there some setting I may have incorrect in the PVFS2 setup? > > > I have a std/default Rocks Cluster (4.2.1) PVFS2 roll setup with one > > > meta data server, and two other compute-I/O nodes. > > > > I doubt if it is a setup related issue since the I/O completed. > > Can you also eliminate one more source of errors by having a single > > MDS server and a single I/O server to begin with? We can start > > narrowing it down faster that way.. > > > > > > > > Appreciate any suggestions. > > Good luck, > > thanks for the report and keep us posted! > > Murali > > > > > Regards > > > Mark > > > _______________________________________________ > > > Pvfs2-users mailing list > > > [email protected] > > > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users > > > > > >
config-logs.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Pvfs2-users mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
