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

[Dorigo Alvise (PSI)]

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