[gpfsug-discuss] Portability interface

Tue Sep 22 16:47:09 BST 2020

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-request at spectrumscale.org
To:	gpfsug-discuss at spectrumscale.org
Date:	09/22/2020 05:18 AM
Subject:	[EXTERNAL] gpfsug-discuss Digest, Vol 104, Issue 23
Sent by:	gpfsug-discuss-bounces at spectrumscale.org

Send gpfsug-discuss mailing list submissions to
		 gpfsug-discuss at 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-request at spectrumscale.org

You can reach the person managing the list at
		 gpfsug-discuss-owner at 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.dorigo at psi.ch>
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Subject: Re: [gpfsug-discuss] Checking if a AFM-managed file is still
		 inflight
Message-ID: <7BB1DD94-E99C-4A66-BAF2-BE287EE5752C at psi.ch>
Content-Type: text/plain; charset="utf-8"

Thank you Venkat, the ?dirty? and ?append? flags seem quite useful.

   A

Da: <gpfsug-discuss-bounces at spectrumscale.org> per conto di Venkateswara R
Puvvada <vpuvvada at in.ibm.com>
Risposta: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Data: luned?, 21 settembre 2020 12:57
A: gpfsug main discussion list <gpfsug-discuss at 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 (vpuvvada at in.ibm.com)

From:        "Dorigo Alvise (PSI)" <alvise.dorigo at psi.ch>
To:        gpfsug main discussion list <gpfsug-discuss at 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-bounces at 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-bounces at spectrumscale.org> per conto di Olaf Weiser
<olaf.weiser at de.ibm.com>
Risposta: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Data: luned?, 21 settembre 2020 11:55
A: "gpfsug-discuss at spectrumscale.org" <gpfsug-discuss at spectrumscale.org>
Cc: "gpfsug-discuss at spectrumscale.org" <gpfsug-discuss at 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.dorigo at psi.ch>
Sent by: gpfsug-discuss-bounces at spectrumscale.org
To: gpfsug main discussion list <gpfsug-discuss at 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.buzzard at strath.ac.uk>
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Subject: [gpfsug-discuss] Portability interface
Message-ID: <4b586251-d208-8535-925a-311023af3dd6 at 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
***********************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200922/1ff4d732/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200922/1ff4d732/attachment-0002.gif>