<html><body><p><font size="2" color="#1D1C1D">You are correct, the &quot;identical architecture&quot; means the same machine hardware name as shown by the -m option of the uname command.</font><br><br><font size="2">Thanks,</font><br><font size="2">Tru.</font><br><br><img width="16" height="16" src="cid:1__=0ABB0F78DFC5F40B8f9e8a93df938690918c0AB@" border="0" alt="Inactive hide details for gpfsug-discuss-request---09/22/2020 05:18:26 AM---Send gpfsug-discuss mailing list submissions to  gp"><font size="2" color="#424282">gpfsug-discuss-request---09/22/2020 05:18:26 AM---Send gpfsug-discuss mailing list submissions to  gpfsug-discuss@spectrumscale.org</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">gpfsug-discuss-request@spectrumscale.org</font><br><font size="2" color="#5F5F5F">To:        </font><font size="2">gpfsug-discuss@spectrumscale.org</font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">09/22/2020 05:18 AM</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">[EXTERNAL] gpfsug-discuss Digest, Vol 104, Issue 23</font><br><font size="2" color="#5F5F5F">Sent by:        </font><font size="2">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">Send gpfsug-discuss mailing list submissions to<br>                 gpfsug-discuss@spectrumscale.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>                 </font></tt><tt><font size="2"><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><tt><font size="2">&nbsp;<br>or, via email, send a message with subject or body 'help' to<br>                 gpfsug-discuss-request@spectrumscale.org<br><br>You can reach the person managing the list at<br>                 gpfsug-discuss-owner@spectrumscale.org<br><br>When replying, please edit your Subject line so it is more specific<br>than &quot;Re: Contents of gpfsug-discuss digest...&quot;<br><br><br>Today's Topics:<br><br> &nbsp; 1. Re: Checking if a AFM-managed file is still                 inflight<br> &nbsp; &nbsp; &nbsp;(Dorigo Alvise (PSI))<br> &nbsp; 2. Portability interface (Jonathan Buzzard)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Mon, 21 Sep 2020 11:17:35 +0000<br>From: &quot;Dorigo Alvise (PSI)&quot; &lt;alvise.dorigo@psi.ch&gt;<br>To: gpfsug main discussion list &lt;gpfsug-discuss@spectrumscale.org&gt;<br>Subject: Re: [gpfsug-discuss] Checking if a AFM-managed file is still<br>                 inflight<br>Message-ID: &lt;7BB1DD94-E99C-4A66-BAF2-BE287EE5752C@psi.ch&gt;<br>Content-Type: text/plain; charset=&quot;utf-8&quot;<br><br>Thank you Venkat, the ?dirty? and ?append? flags seem quite useful.<br><br> &nbsp; A<br><br><br><br>Da: &lt;gpfsug-discuss-bounces@spectrumscale.org&gt; per conto di Venkateswara R Puvvada &lt;vpuvvada@in.ibm.com&gt;<br>Risposta: gpfsug main discussion list &lt;gpfsug-discuss@spectrumscale.org&gt;<br>Data: luned?, 21 settembre 2020 12:57<br>A: gpfsug main discussion list &lt;gpfsug-discuss@spectrumscale.org&gt;<br>Oggetto: Re: [gpfsug-discuss] Checking if a AFM-managed file is still inflight<br><br>tspcacheutil &lt;file path&gt;, this command provides information about the file's replication state. You can also run policy to find these files.<br><br>Example:<br><br>tspcacheutil /gpfs/gpfs1/sw2/1.txt<br>inode: ino=524290 gen=235142808 uid=1000 gid=0 size=3 mode=0200100777 nlink=1<br> &nbsp; &nbsp; &nbsp; ctime=1600366912.382081156 mtime=1600275424.692786000<br> &nbsp; &nbsp; &nbsp; cached 1 &nbsp;hasState 1 &nbsp;local 0<br> &nbsp; &nbsp; &nbsp; create 0 &nbsp;setattr &nbsp;0 &nbsp;dirty 0 &nbsp;link 0 &nbsp;append 0<br>pcache: parent ino=524291 foldval=0x6AE011D4 nlink=1<br>remote: ino=56076 size=3 nlink=1 fhsize=24 version=0<br> &nbsp; &nbsp; &nbsp; &nbsp;ctime=1600376836.408694099 mtime=1600275424.692786000<br><br>Cached - File is cached. For directory, readdir+lookup is completed.<br>hashState - file/dir have remote attributes for the replication.<br>local - file/dir is local, &nbsp;won't be replicated to home or not revalidated with home.<br>Create - file/dir is newly created, not yet replicated<br>Setattr - Attributes (chown, chmod, mmchattr , setACL, setEA etc..) &nbsp;are changed on dir/file, but not replicated yet.<br>Dirty - file have been changed in the cache, but not replicated yet. For directory this means that files inside it have been removed or renamed.<br>Link - hard link for the file have been created, but not replicated yet.<br>Append - file have been appended, but not replicated yet. For directory this is complete bit which indicates &nbsp;that readddir was performed.<br><br>~Venkat (vpuvvada@in.ibm.com)<br><br><br><br>From: &nbsp; &nbsp; &nbsp; &nbsp;&quot;Dorigo Alvise (PSI)&quot; &lt;alvise.dorigo@psi.ch&gt;<br>To: &nbsp; &nbsp; &nbsp; &nbsp;gpfsug main discussion list &lt;gpfsug-discuss@spectrumscale.org&gt;<br>Date: &nbsp; &nbsp; &nbsp; &nbsp;09/21/2020 04:02 PM<br>Subject: &nbsp; &nbsp; &nbsp; &nbsp;[EXTERNAL] Re: [gpfsug-discuss] Checking if a AFM-managed file is still &nbsp; &nbsp; &nbsp; &nbsp;inflight<br>Sent by: &nbsp; &nbsp; &nbsp; &nbsp;gpfsug-discuss-bounces@spectrumscale.org<br>________________________________<br><br><br><br>Information reported by that command (both at cache and home side) are size, blocks, block size, and times.<br>I think it cannot be enough to decide that AFM completed the transfer of a file.<br>Did I possibly miss something else ?<br>It would be nice to have a flag (like that one reported by the policy, flags ?P? ? managed by AFM ? and ?w? ? beeing transferred -) that can help us to know if AFM considers the file synced to home or not yet.<br><br> &nbsp; Alvise<br><br>Da: &lt;gpfsug-discuss-bounces@spectrumscale.org&gt; per conto di Olaf Weiser &lt;olaf.weiser@de.ibm.com&gt;<br>Risposta: gpfsug main discussion list &lt;gpfsug-discuss@spectrumscale.org&gt;<br>Data: luned?, 21 settembre 2020 11:55<br>A: &quot;gpfsug-discuss@spectrumscale.org&quot; &lt;gpfsug-discuss@spectrumscale.org&gt;<br>Cc: &quot;gpfsug-discuss@spectrumscale.org&quot; &lt;gpfsug-discuss@spectrumscale.org&gt;<br>Oggetto: Re: [gpfsug-discuss] Checking if a AFM-managed file is still inflight<br><br>do you looking fo smth like this:<br>mmafmlocal ls filename &nbsp; &nbsp;or stat filename<br><br><br><br><br><br>----- Original message -----<br>From: &quot;Dorigo Alvise (PSI)&quot; &lt;alvise.dorigo@psi.ch&gt;<br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: gpfsug main discussion list &lt;gpfsug-discuss@spectrumscale.org&gt;<br>Cc:<br>Subject: [EXTERNAL] [gpfsug-discuss] Checking if a AFM-managed file is still inflight<br>Date: Mon, Sep 21, 2020 10:45 AM<br><br><br>Dear GPFS users,<br>I know that through a policy one can know if a file is still being transferred from the cache to your home by AFM.<br><br>I wonder if there is another method @cache or @home side, faster and less invasive (a policy, as far as I know, can put some pressure on the system when there are many files).<br>I quickly checked mmlsattr that seems not to be AFM-aware (but there is a flags field that can show several things, like compression status, archive, etc).<br><br>Any suggestion ?<br><br>Thanks in advance,<br><br> &nbsp; Alvise<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><tt><font size="2"><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><tt><font size="2">&nbsp;<br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><tt><font size="2"><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><tt><font size="2">&nbsp;<br><br><br><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: &lt;</font></tt><tt><font size="2"><a href="http://gpfsug.org/pipermail/gpfsug-discuss/attachments/20200921/62d55b7e/attachment-0001.html">http://gpfsug.org/pipermail/gpfsug-discuss/attachments/20200921/62d55b7e/attachment-0001.html</a></font></tt><tt><font size="2">&nbsp;&gt;<br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 22 Sep 2020 10:18:05 +0100<br>From: Jonathan Buzzard &lt;jonathan.buzzard@strath.ac.uk&gt;<br>To: gpfsug main discussion list &lt;gpfsug-discuss@spectrumscale.org&gt;<br>Subject: [gpfsug-discuss] Portability interface<br>Message-ID: &lt;4b586251-d208-8535-925a-311023af3dd6@strath.ac.uk&gt;<br>Content-Type: text/plain; charset=utf-8; format=flowed<br><br><br>I have a question about using RPM's for the portability interface on <br>different CPU's.<br><br>According to /usr/lpp/mmfs/src/README<br><br> &nbsp; &nbsp;The generated RPM can ONLY be deployed to the machine with<br> &nbsp; &nbsp;identical architecture, distribution level, Linux kernel version<br> &nbsp; &nbsp;and GPFS version.<br><br>So does this mean that if I have a heterogeneous cluster with some <br>machines on &nbsp;Skylake and some on Sandy Bridge but all running on say <br>RHEL 7.8 and all using GPFS 5.0.5 I have to have different RPM's for the <br>two CPU's?<br><br>Or when it says &quot;identical architecture&quot; does it mean x86-64, ppc etc. <br>and not variations with the x86-64, ppc class? Assuming some minimum <br>level is met.<br><br>Obviously the actual Linux kernel being stock RedHat would be the same <br>on every machine regardless of whether it's Skylake or Sandy Bridge, or <br>even for that matter an AMD processor.<br><br>Consequently it seems strange that I would need different portability <br>interfaces. Would it help to generate the portability layer RPM's on a <br>Sandy Bridge machine and work no the presumption anything that runs on <br>Sandy Bridge will run on Skylake?<br><br><br>JAB.<br><br>-- <br>Jonathan A. Buzzard &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Tel: +44141-5483420<br>HPC System Administrator, ARCHIE-WeSt.<br>University of Strathclyde, John Anderson Building, Glasgow. G4 0NG<br><br><br>------------------------------<br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><tt><font size="2"><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><tt><font size="2">&nbsp;<br><br><br>End of gpfsug-discuss Digest, Vol 104, Issue 23<br>***********************************************<br><br></font></tt><br><br><BR>
</body></html>