[gpfsug-discuss] Does an AFM recovery stop AFM from recalling files?

[Venkateswara R Puvvada]

While the recovery is running, reading the uncached files (evicted files) 
gets blocked until the recovery completes queueing the recovery 
operations. This is to make sure that recovery executes all the dependent 
operations first. For example, evicted file might have been renamed in the 
cache, but not yet  replicated to home site and the fileset went into the 
recovery state. First recovery have to perform rename operation to the 
home site  and then allow read operation on it. Read on the uncached files 
may get blocked if the cache state is in 
Recovery/NeedsResync/Unmounted/Dropped/Stopped states.

~Venkat (vpuvvada at in.ibm.com)



From:   "Billich  Heinrich Rainer (ID SD)" <heinrich.billich at id.ethz.ch>
To:     gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date:   01/20/2020 08:50 PM
Subject:        [EXTERNAL] [gpfsug-discuss] Does an AFM recovery stop AFM 
from recalling files?
Sent by:        gpfsug-discuss-bounces at spectrumscale.org



Hello,

Do AFM recalls from home to cache still work when a fileset is in state 
‘Recovery’? Are there any other states that allow to  write/read from 
cache but won’t allow to recall from home? We announced to users that they 
can continue to work on cache while a recovery is running. But we got 
report that evicted files weren’t available. NFS did work, I could read 
the files on home via the nfs mount in /var/mmfs/afm/<filesystem>-<fsid>/. 
But AFM didn’t recall. If recalls are done by entries in the AFM Queue I 
see why, but is this the case?
 
Kind regards,
 
Heiner_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=92LOlNh2yLzrrGTDA7HnfF8LFr55zGxghLZtvZcZD7A&m=zwJSIhs7R020CQybqTb86CxBGIhtULCJo_QEggx05Y4&s=TGxHcd4HcDF0hv621ilqJ56r26Ah4rlmNM7PcJ3yLEA&e= 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200120/ac5745bd/attachment-0002.htm>