Hello Venkat,
Thank you very much, upgrading to 5.0.4.1 did indeed fix the issue. AFM now
compiles the list of pending changes in a few hours. Before we estimated
>20days.
We had to increase disk space in /var/mmfs/afm/ and /var/mmfs/tmp/ to allow
AFM to store all intermediate file lists.
Hi,
>The dirtyDirs file holds 130’000 lines, which don’t seem to be so many.
But dirtyDirDirents holds about 80M entries. Can we estimate how long it
will take to finish processing?
Yes, this is the major problem fixed as mentioned in the APAR below. The
dirtyDirs file is opened for the each
Hello Venkat,
thank you, this seems to match our issue. did trace tspcachescan and do see a
long series of open()/read()/close() to the dirtyDirs file. The dirtyDirs file
holds 130’000 lines, which don’t seem to be so many. But dirtyDirDirents holds
about 80M entries. Can we estimate how
AFM maintains in-memory queue at the gateway node to keep track of changes
happening on the fileset. If the in-memory queue is lost (memory pressure,
daemon shutdown etc..), AFM runs recovery process which involves creating
the snapshot, running the policy scan and finally queueing the
Venkat,
for awareness and response.
Thanks,Lyle
- Original message -From: "Billich Heinrich Rainer (ID SD)" Sent by: gpfsug-discuss-boun...@spectrumscale.orgTo: gpfsug main discussion list Cc:Subject: [EXTERNAL] [gpfsug-discuss] AFM Recovery of SW cache does a full scan of home - is
Hello,
still new to AFM, so some basic question on how Recovery works for a SW cache:
we have an AFM SW cache in recovery mode – recovery first did run policies on
the cache cluster, but now I see a ‘tcpcachescan’ process on cache slowly
scanning home via nfs. Single host, single process, no
