[CMake] Problem writing on GPFS.

[P. A. Cheeseman]

     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/42292760/attachment-0001.html>