<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.im
{mso-style-name:im;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> 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 ...<o:p></o:p></span></p><div style='mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;padding:0in 0in 1.0pt 0in'><p class=MsoNormal style='border:none;padding:0in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>#include <iostream><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>#include <fstream><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>using namespace std;<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>main()<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>{<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>ofstream file;<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>std::string message;<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>message += "Line 00\n";<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>message += "Line 01\n";<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>// Enough of these to create 1K ... //<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>file.open("popeye",ios::binary);<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>file << message;<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>file.close();<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>return(0);<o:p></o:p></span></p><div style='mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;padding:0in 0in 1.0pt 0in'><p class=MsoNormal style='border:none;padding:0in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>}<o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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 :-)).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> 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).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> 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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> 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 :-).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> Thanks to all,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> Phil<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> P. A. Cheeseman<br> aai@purdue.edu<br> 765.496.8224<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Samuel Trahan - NOAA Affiliate [mailto:samuel.trahan@noaa.gov] <br><b>Sent:</b> Tuesday, February 10, 2015 14:44<br><b>To:</b> aai@purdue.edu<br><b>Cc:</b> cmake@cmake.org<br><b>Subject:</b> Re: [CMake] Problem writing on GPFS.<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Does anyone know of a workaround for this which does not require upgrading GPFS or changing compilers?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Feb 10, 2015 at 2:24 PM, P. A. Cheeseman <<a href="mailto:aai@purdue.edu" target="_blank">aai@purdue.edu</a>> wrote:<o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'> I want to thank Rolf here for his advice because I failed to<br>do so in an off line reply.<br><br> Shortly after I replied to Rolf's note, I received notification from<br>IBM that the problem is related to our version of GPFS (4.1.0-2).<br><br> Versions 4.1.0-3 and later apparently do not have the problem.<br><br> Best regards,<br><span class=im> Phil</span><br><br><span class=im> P. A. Cheeseman</span><br><span class=im> <a href="mailto:aai@purdue.edu">aai@purdue.edu</a></span><br><span class=im> 765.496.8224</span><br><br><o:p></o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>> -----Original Message-----<br>> From: Rolf Eike Beer [mailto:<a href="mailto:eike@sf-mail.de">eike@sf-mail.de</a>]<br>> Sent: Tuesday, February 10, 2015 13:44<br>> To: <a href="mailto:cmake@cmake.org">cmake@cmake.org</a>; <a href="mailto:aai@purdue.edu">aai@purdue.edu</a><br>> Subject: Re: [CMake] Problem writing on GPFS.<br>><br>> P. A. Cheeseman wrote:<br>> > System: RHEL6 (2.6.32-504.8.1.el6.x86_64)<br>> > Hardware: Various cluster nodes.<br>><br>> > A C code with explicit writev() calls, with a NULL pointer in the<br>> > first iovec entry, also reproduces the behavior. When the NULL is<br>> > part of any entry other than the first, the code runs identically for<br>> > all storage.<br>><br>> I would suggest contacting Red Hat. This sounds for me like a bug in the<br>GPFS<br>> code, especially since the call succeeds if the (NULL, 0) pair is in a<br>later pair.<br>><br>> Other than that, I don't see a reason why g++ should emit such a call.<br>Should<br>> probably be reported to the gcc guys. Or maybe this is just something in<br>your<br>> libc, so gcc isn't at fault at all. Probably time for the Red Hat guys to<br>> investigate, too ;)<br>><br>> Eike<br>> --<o:p></o:p></p></div></div><div><div><p class=MsoNormal>--<br><br>Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br><br>Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br><br>Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br><br>CMake Support: <a href="http://cmake.org/cmake/help/support.html" target="_blank">http://cmake.org/cmake/help/support.html</a><br>CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" target="_blank">http://cmake.org/cmake/help/training.html</a><br><br>Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br><br>Follow this link to subscribe/unsubscribe:<br><a href="http://public.kitware.com/mailman/listinfo/cmake" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>