<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>I've got a PMR open about this ... Will email you the number directly.</div>
<div><br>
</div>
<div>Looking at the man page for ld.gold, it looks to set '<b style="color: rgb(51, 51, 51); font-family: inherit; font-size: 12px; orphans: 2; widows: 2;">--posix-fallocate'</b>&nbsp;by default. In fact, testing with '-Xlinker -no-posix-fallocate' does indeed make
 the code compile.</div>
<div><br>
</div>
<div>Simon</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>&quot;<a href="mailto:vpuvvada@in.ibm.com">vpuvvada@in.ibm.com</a>&quot; &lt;<a href="mailto:vpuvvada@in.ibm.com">vpuvvada@in.ibm.com</a>&gt;<br>
<span style="font-weight:bold">Date: </span>Wednesday, 23 August 2017 at 13:36<br>
<span style="font-weight:bold">To: </span>&quot;<a href="mailto:gpfsug-discuss@spectrumscale.org">gpfsug-discuss@spectrumscale.org</a>&quot; &lt;<a href="mailto:gpfsug-discuss@spectrumscale.org">gpfsug-discuss@spectrumscale.org</a>&gt;, Simon Thompson &lt;<a href="mailto:S.J.Thompson@bham.ac.uk">S.J.Thompson@bham.ac.uk</a>&gt;<br>
<span style="font-weight:bold">Subject: </span>Re: [gpfsug-discuss] AFM weirdness<br>
</div>
<div><br>
</div>
<div>
<div><font size="2" face="sans-serif">I believe this error is result of preallocation failure, but traces are needed to confirm this. &nbsp;AFM caching modes does not support preallocation of blocks (ex. using fallocate()). This feature is supported only in AFM
 DR.</font><br>
<br>
<font size="2" face="sans-serif">~Venkat (<a href="mailto:vpuvvada@in.ibm.com">vpuvvada@in.ibm.com</a>)</font><br>
<br>
<br>
<br>
<font size="1" color="#5f5f5f" face="sans-serif">From: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size="1" face="sans-serif">&quot;Simon Thompson (IT Research Support)&quot; &lt;<a href="mailto:S.J.Thompson@bham.ac.uk">S.J.Thompson@bham.ac.uk</a>&gt;</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">To: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size="1" face="sans-serif">gpfsug main discussion list &lt;<a href="mailto:gpfsug-discuss@spectrumscale.org">gpfsug-discuss@spectrumscale.org</a>&gt;</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Date: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size="1" face="sans-serif">08/23/2017 03:48 PM</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Subject: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size="1" face="sans-serif">Re: [gpfsug-discuss] AFM weirdness</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Sent by: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size="1" face="sans-serif"><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a></font><br>
<hr noshade="">
<br>
<br>
<br>
<tt><font size="2">OK so I checked and if I run directly on the &quot;AFM&quot; FS in a different &quot;non<br>
AFM&quot; directory, it works fine, so its something AFM related ...<br>
<br>
Simon<br>
<br>
On 23/08/2017, 11:11, &quot;<a href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a> on behalf<br>
of Simon Thompson (IT Research Support)&quot;<br>
&lt;<a href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a> on behalf of<br>
<a href="mailto:S.J.Thompson@bham.ac.uk">S.J.Thompson@bham.ac.uk</a>&gt; wrote:<br>
<br>
&gt;We're using an AFM cache from our HPC nodes to access data in another GPFS<br>
&gt;cluster, mostly this seems to be working fine, but we've just come across<br>
&gt;an interesting problem with a user using gfortran from the GCC 5.2.0<br>
&gt;toolset.<br>
&gt;<br>
&gt;When linking their code, they get a &quot;no space left on device&quot; error back<br>
&gt;from the linker. If we do this on a node that mounts the file-system<br>
&gt;directly (I.e. Not via AFM cache), then it works fine.<br>
&gt;<br>
&gt;We tried with GCC 4.5 based tools and it works OK, but the difference<br>
&gt;there is that 4.x uses ld and 5x uses ld.gold.<br>
&gt;<br>
&gt;If we strike the ld.gold when using AFM, we see:<br>
&gt;<br>
&gt;stat(&quot;program&quot;, {st_mode=S_IFREG|0775, st_size=248480, ...}) = 0<br>
&gt;unlink(&quot;program&quot;) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0<br>
&gt;open(&quot;program&quot;, O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0777) = 30<br>
&gt;fstat(30, {st_mode=S_IFREG|0775, st_size=0, ...}) = 0<br>
&gt;fallocate(30, 0, 0, 248480) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = -1 ENOSPC (No space left on<br>
&gt;device)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;Vs when running directly on the file-system:<br>
&gt;stat(&quot;program&quot;, {st_mode=S_IFREG|0775, st_size=248480, ...}) = 0<br>
&gt;unlink(&quot;program&quot;) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0<br>
&gt;open(&quot;program&quot;, O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0777) = 30<br>
&gt;fstat(30, {st_mode=S_IFREG|0775, st_size=0, ...}) = 0<br>
&gt;fallocate(30, 0, 0, 248480) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;Anyone seen anything like this before?<br>
&gt;<br>
&gt;... Actually I'm about to go off and see if its a function of AFM, or<br>
&gt;maybe something to do with the FS in use (I.e. Make a local directory on<br>
&gt;the filesystem on the &quot;AFM&quot; FS and see if that works ...)<br>
&gt;<br>
&gt;Thanks<br>
&gt;<br>
&gt;Simon<br>
&gt;<br>
&gt;_______________________________________________<br>
&gt;gpfsug-discuss mailing list<br>
&gt;gpfsug-discuss at spectrumscale.org<br>
&gt;</font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&amp;d=DwICAg&amp;c=jf_iaSHvJObTbx-siA1ZOg&amp;r=92LOlNh2yLzrrGTDA7HnfF8LFr55zGxghLZtvZcZD7A&amp;m=UqTzoU-bx454OgyeB4f0Nrruvs7yYAxFutzIe2eKmnc&amp;s=8E5opHyyAwomLS8kdxpvKCvf6sdKBLlfZvx6wDdaZy4&amp;e="><tt><font size="2">https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&amp;d=DwICAg&amp;c=jf_iaSHvJObTbx-siA1ZOg&amp;r=92LOlNh2yLzrrGTDA7HnfF8LFr55zGxghLZtvZcZD7A&amp;m=UqTzoU-bx454OgyeB4f0Nrruvs7yYAxFutzIe2eKmnc&amp;s=8E5opHyyAwomLS8kdxpvKCvf6sdKBLlfZvx6wDdaZy4&amp;e=</font></tt></a><tt><font size="2"><br>
<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at spectrumscale.org<br>
</font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&amp;d=DwICAg&amp;c=jf_iaSHvJObTbx-siA1ZOg&amp;r=92LOlNh2yLzrrGTDA7HnfF8LFr55zGxghLZtvZcZD7A&amp;m=UqTzoU-bx454OgyeB4f0Nrruvs7yYAxFutzIe2eKmnc&amp;s=8E5opHyyAwomLS8kdxpvKCvf6sdKBLlfZvx6wDdaZy4&amp;e="><tt><font size="2">https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&amp;d=DwICAg&amp;c=jf_iaSHvJObTbx-siA1ZOg&amp;r=92LOlNh2yLzrrGTDA7HnfF8LFr55zGxghLZtvZcZD7A&amp;m=UqTzoU-bx454OgyeB4f0Nrruvs7yYAxFutzIe2eKmnc&amp;s=8E5opHyyAwomLS8kdxpvKCvf6sdKBLlfZvx6wDdaZy4&amp;e=</font></tt></a><tt><font size="2"><br>
<br>
</font></tt><br>
<br>
<br>
</div>
</div>
</span>
</body>
</html>