[gpfsug-discuss] Checking if a AFM-managed file is still inflight

[Venkateswara R Puvvada]

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_gpfsug.org/attachments/20200921/407c76cf/attachment-0002.htm>