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