Thank you Venkat, the “dirty” and “append” flags seem quite useful.
A Da: <[email protected]> per conto di Venkateswara R Puvvada <[email protected]> Risposta: gpfsug main discussion list <[email protected]> Data: lunedì, 21 settembre 2020 12:57 A: gpfsug main discussion list <[email protected]> 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 ([email protected]) From: "Dorigo Alvise (PSI)" <[email protected]> To: gpfsug main discussion list <[email protected]> Date: 09/21/2020 04:02 PM Subject: [EXTERNAL] Re: [gpfsug-discuss] Checking if a AFM-managed file is still inflight Sent by: [email protected] ________________________________ 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: <[email protected]> per conto di Olaf Weiser <[email protected]> Risposta: gpfsug main discussion list <[email protected]> Data: lunedì, 21 settembre 2020 11:55 A: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> 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)" <[email protected]> Sent by: [email protected] To: gpfsug main discussion list <[email protected]> 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
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
