Raul: I'm not seeing any reference to OrangeFS/PVFS. Are you sorting an OrangeFS/PVFS file? Does this code work correctly against the local filesystem?
Becky On Wed, Mar 12, 2014 at 5:55 PM, Kist <[email protected]> wrote: > So, here we go: > > nothing on /var/log/messages, pvfs2-client.log, pvfs2-server.log. > > I am using the kernel module. > > Using 2.8.7 version. > > And about the strace... this client I'm using is queueing (does this word > exist?) some HPC jobs in the cluster... it seems to prepare a python script > to submit them, I'll try to edit the script so it includes the strace in > the invocation. It's a little bit messy =] > > My output in the node is this > > =========== > error in startExecution() for tool Output (2) : Function not implemented > > ++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++ Signal Handler Invoked +++++++ > +++++++ Signal : SIGSEGV +++++++ > +++++++ Meaning: Invalid memory reference +++++++ > ++++++++++++++++++++++++++++++++++++++++++++++++++ > > > Stack trace is: > > /net/gis/tools/opencps/opencps-time-3.1-2013-06-26/bin/linux64/lib/libbluefin_tools.so: > ogi::backtraceutil::get(int)+0x82 > > /net/gis/tools/opencps/opencps-time-3.1-2013-06-26/bin/linux64/lib/libbluefin_tools.so: > ogi::backtraceutil::maybePrint(std::ostream&)+0x62 > > /net/gis/tools/opencps/opencps-time-3.1-2013-06-26/bin/linux64/lib/libopencps_engine.so: > ogi::SignalHandling::handleSignal(int)+0x1e1 > /lib64/libc.so.6() [0x309f032900] > > /net/gis/tools/opencps/opencps-time-3.1-2013-06-26/bin/linux64/lib/libopencps_engine.so: > void std::__insertion_sort<__gnu_cxx::__normal_iterator<long*, > std::vector<long, std::allocator<long> > >, ogi::IndexComparator<unsigned > long, int> >(__gnu_cxx::__normal_iterator<long*, std::vector<long, > std::allocator<long> > >, __gnu_cxx::__normal_iterator<long*, > std::vector<long, std::allocator<long> > >, ogi::IndexComparator<unsigned > long, int>)+0x31 > > /net/gis/tools/opencps/opencps-time-3.1-2013-06-26/bin/linux64/lib/libopencps_engine.so: > void std::__merge_sort_with_buffer<__gnu_cxx::__normal_iterator<long*, > std::vector<long, std::allocator<long> > >, long*, > ogi::IndexComparator<unsigned long, int> > >(__gnu_cxx::__normal_iterator<long*, std::vector<long, > std::allocator<long> > >, __gnu_cxx::__normal_iterator<long*, > std::vector<long, std::allocator<long> > >, long*, > ogi::IndexComparator<unsigned long, int>)+0x64 > > /net/gis/tools/opencps/opencps-time-3.1-2013-06-26/bin/linux64/lib/libopencps_engine.so: > void std::__stable_sort_adaptive<__gnu_cxx::__normal_iterator<long*, > std::vector<long, std::allocator<long> > >, long*, long, > ogi::IndexComparator<unsigned long, int> > >(__gnu_cxx::__normal_iterator<long*, std::vector<long, > std::allocator<long> > >, __gnu_cxx::__normal_iterator<long*, > std::vector<long, std::allocator<long> > >, long*, long, > ogi::IndexComparator<unsigned long, int>)+0xd3 > > /net/gis/tools/opencps/opencps-time-3.1-2013-06-26/bin/linux64/lib/libopencps_engine.so: > ogi::OutputMSeis::flush()+0x119 > > /net/gis/tools/opencps/opencps-time-3.1-2013-06-26/bin/linux64/lib/libopencps_engine.so: > ogi::OutputMSeis::finishExecution()+0x1c > > /net/gis/tools/opencps/opencps-time-3.1-2013-06-26/bin/linux64/lib/libbluefin_tools.so: > ogi::Tool::finishExecutionInternal()+0x17 > ========== > > > > > > > > > > > > > > On Tue, Mar 11, 2014 at 12:54 PM, Mike Marshall <[email protected]>wrote: > >> Here is our implementation of lock in the kernel module: >> >> int pvfs2_lock(struct file *f, int flags, struct file_lock *lock) >> { >> return -ENOSYS; >> } >> >> Some things (sqllite is one I noticed) pitch a big fit if there is no >> file lock >> mechanism supported in the kernel... >> >> -Mike >> >> >> On Tue, Mar 11, 2014 at 11:29 AM, Kist <[email protected]> wrote: >> >>> Hi!! >>> >>> Thanks for the answers! >>> >>> I was just looking at the /var/log/messages, yesterday, when a small >>> fire started in the building's energy board and we had to evacuate it. >>> I'll have access to the cluster again tomorrow (I hope). >>> >>> Then I'll check for everything you suggested. >>> Sorry for the delay. >>> :) >>> >>> >>> >>> >>> On Tue, Mar 11, 2014 at 9:50 AM, Sam Sampson <[email protected]>wrote: >>> >>>> You might try running strace on the client application, and seeing what >>>> file system call results in the error. >>>> >>>> Thanks, >>>> Sam Sampson >>>> Omnibond Systems >>>> >>>> >>>> >>>> On Mon, Mar 10, 2014 at 1:56 PM, Becky Ligon <[email protected]>wrote: >>>> >>>>> Raul: >>>>> >>>>> Can you give me the exact error message that you are seeing? Is the >>>>> error message showing up in /var/log/messages, pvfs2-client.log, >>>>> pvfs2-server.log, or stdout from your program? >>>>> >>>>> Also, are you linking the application with the pvfs2 libraries or just >>>>> using the kernel module? >>>>> >>>>> Which version of OrangeFS are you using? >>>>> >>>>> Becky >>>>> >>>>> >>>>> On Mon, Mar 10, 2014 at 12:26 PM, Rob Latham <[email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 03/10/2014 08:45 AM, Kist wrote: >>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> I'm testing OrangeFS (pvfs2) in a small virtual cluster before we >>>>>>> try it >>>>>>> on a big cluster for seismic processing. >>>>>>> I am running 8 CentOS with 2.6 kernel. All of them are servers (io) >>>>>>> and >>>>>>> clients and the headnode is the metadata server. >>>>>>> >>>>>>> So far it's the best DFS I found and our standalone tools are working >>>>>>> alright on it but when I try to use our libraries with a different >>>>>>> client (as a plugin in another tool) I get a "Function not >>>>>>> implemented" >>>>>>> error. >>>>>>> >>>>>>> I have no access to the source code of the client I'm using and, now, >>>>>>> I'm looking for the pvfs2 source code for "PVFS_ENOSYS" ("Function >>>>>>> not >>>>>>> implemented") references but it seems a little bit more work than it >>>>>>> should be. >>>>>>> >>>>>>> So, I would like to know if you guys have some ideas of what could >>>>>>> it be >>>>>>> (lock?) or some magic flag I can set to check what is this. >>>>>>> >>>>>> >>>>>> If you are using the kernel interface, the one routine we've >>>>>> explicitly disabled is fcntl() with the F_SETLKW and related flags. >>>>>> >>>>>> slang did this years and years ago >>>>>> >>>>>> http://www.orangefs.org/fisheye/orangefs/changelog/orangefs?cs=6613 >>>>>> >>>>>> The other thing to look at is certain kinds of mmap operations, but I >>>>>> never, even at my peak, remembered all the various details about that >>>>>> one... >>>>>> >>>>>> ==rob >>>>>> >>>>>> -- >>>>>> Rob Latham >>>>>> Mathematics and Computer Science Division >>>>>> Argonne National Lab, IL USA >>>>>> _______________________________________________ >>>>>> Pvfs2-users mailing list >>>>>> [email protected] >>>>>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Becky Ligon >>>>> OrangeFS Support and Development >>>>> Omnibond Systems >>>>> Anderson, South Carolina >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pvfs2-users mailing list >>>>> [email protected] >>>>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pvfs2-users mailing list >>>> [email protected] >>>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users >>>> >>>> >>> >>> >>> -- >>> Raul Kist >>> >>> >>> _______________________________________________ >>> Pvfs2-users mailing list >>> [email protected] >>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users >>> >>> >> > > > -- > Raul Kist > > > _______________________________________________ > Pvfs2-users mailing list > [email protected] > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users > >
_______________________________________________ Pvfs2-users mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
