[CMake] Problem writing on GPFS.

[Samuel Trahan - NOAA Affiliate]

Phil,

Could you give me a ticket or bug number (however they track it) for GPFS
that describes this as a known bug?  I will need that when submitting a
ticket to my organization's helpdesk.  This problem is quite a lot larger
than CMake: all C++ programs will break.

Sincerely,
Sam Trahan

On Tue, Feb 10, 2015 at 4:09 PM, P. A. Cheeseman <aai at purdue.edu> wrote:

>      Reading into the final resolution of the IBM ticket tipped me to
> where the writev() calls originate in the C++ run-time.  The amount of data
> has to be 1K or more before writev() is used.  Then the NULL pointer in the
> iovec is assured with our versions of Gcc/G++.  I've just compiled and run
> ...
>
>
>
> #include <iostream>
>
> #include <fstream>
>
> using namespace std;
>
> main()
>
> {
>
> ofstream file;
>
> std::string message;
>
>
>
> message += "Line                                           00\n";
>
> message += "Line                                           01\n";
>
> //  Enough of these to create 1K ... //
>
>
>
> file.open("popeye",ios::binary);
>
> file << message;
>
> file.close();
>
>
>
> return(0);
>
> }
>
>
>
> to mimic what happens in cmFileCommand::HandleWriteCommand().  The
> writev() calls appear in the strace after that.  The workaround until GPFS
> catches up would be to disrupt the approach in HandleWriteCommand by
> pushing out the string(s) in parts less than 1K so the run-time will use
> write() instead of marginal calls to writev() (if you care to go that far
> :-)).
>
>
>
>      Another workaround is to (sigh) build off of GPFS and rsync the
> installation to its final destination, patching any hard coded paths along
> the way (again, sigh).
>
>
>
>      I'm not deep into the chain of handling under RedHat but I suspect
> the iovec is handed down through the system from the compiler run-time
> until it reaches a handler specific to the storage.  I frankly wonder why
> the marginal calls make it out of the compiler run-time.
>
>
>
>      In any case, the Cmake code really isn't at fault, if I'm following
> things correctly.  If I pursue further, I'll be seeing if the compiler
> suite support and/or RedHat can explain the necessity of the NULLs :-).
>
>
>
>                                                                 Thanks to
> all,
>
>                                                                 Phil
>
>
>
>                                                                 P. A.
> Cheeseman
>
> aai at purdue.edu
>
> 765.496.8224
>
>
>
> *From:* Samuel Trahan - NOAA Affiliate [mailto:samuel.trahan at noaa.gov]
> *Sent:* Tuesday, February 10, 2015 14:44
> *To:* aai at purdue.edu
> *Cc:* cmake at cmake.org
>
> *Subject:* Re: [CMake] Problem writing on GPFS.
>
>
>
> Does anyone know of a workaround for this which does not require upgrading
> GPFS or changing compilers?
>
>
>
> On Tue, Feb 10, 2015 at 2:24 PM, P. A. Cheeseman <aai at purdue.edu> wrote:
>
>      I want to thank Rolf here for his advice because I failed to
> do so in an off line reply.
>
>      Shortly after I replied to Rolf's note, I received notification from
> IBM that the problem is related to our version of GPFS (4.1.0-2).
>
>      Versions 4.1.0-3 and later apparently do not have the problem.
>
>                                 Best regards,
>                                 Phil
>
>                                 P. A. Cheeseman
>                                 aai at purdue.edu
>                                 765.496.8224
>
> > -----Original Message-----
> > From: Rolf Eike Beer [mailto:eike at sf-mail.de]
> > Sent: Tuesday, February 10, 2015 13:44
> > To: cmake at cmake.org; aai at purdue.edu
> > Subject: Re: [CMake] Problem writing on GPFS.
> >
> > P. A. Cheeseman wrote:
> > >      System: RHEL6   (2.6.32-504.8.1.el6.x86_64)
> > >      Hardware: Various cluster nodes.
> >
> > >      A C code with explicit writev() calls, with a NULL pointer in the
> > > first iovec entry, also reproduces the behavior.  When the NULL is
> > > part of any entry other than the first, the code runs identically for
> > > all storage.
> >
> > I would suggest contacting Red Hat. This sounds for me like a bug in the
> GPFS
> > code, especially since the call succeeds if the (NULL, 0) pair is in a
> later pair.
> >
> > Other than that, I don't see a reason why g++ should emit such a call.
> Should
> > probably be reported to the gcc guys. Or maybe this is just something in
> your
> > libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to
> > investigate, too ;)
> >
> > Eike
> > --
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150210/ed46ab4e/attachment.html>