<font size=1 face="sans-serif">Billich<font size=2 face="sans-serif">, <tt><font size=2>>The cache filesets holds about 500M used inodes.

Does a specific procedure exist, or is it good enough to just shutdown

scale on the node I want to update? And maybe flush >the queues first

as  far as possible? <br></font></tt><br><tt><font size=2>It is recommended to stop (mmafmctl device stop) the

filesets and perform upgrade if the upgrade duration is short. But if the

upgrade procedure takes too long,</font></tt><font size=2 face="sans-serif"> gateway node can be shutdown, other active gateway node(s) runs recovery

automatically for the filesets owned by the gateway which was shutdown.</font><br><tt><font size=2><br>>If a fileset has a zero length queue of pending transactions to home,

will this avoid any policy scan when a second afm node takes responsibility

for the fileset?</font></tt><br><br><tt><font size=2>Active gateway node(s) always runs recovery with policy

scan even though queue length was zero on other gateway node(s), so it

is possible that recovery on multiple filesets (assuming that in this case

20 filesets) trigger at the same time and which may impact the system performance.

You could limit the  number of parallel recoveries using the afmMaxParallelRecoveries

option. For example set mmchconfig afmMaxParallelRecoveries=5 -i (default

0 means run recovery on all filesets parallelly), and reset to default

later.</font></tt><br><br><font size=2 face="sans-serif">~Venkat (vpuvvada@in.ibm.com)</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      

 </font><font size=1 face="sans-serif">"Billich  Heinrich

Rainer (ID SD)" <heinrich.billich@id.ethz.ch></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      

 </font><font size=1 face="sans-serif">gpfsug main discussion

list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      

 </font><font size=1 face="sans-serif">08/25/2020 08:43 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    

   </font><font size=1 face="sans-serif">[EXTERNAL] [gpfsug-discuss]

AFM cache rolling upgrade with minimal impact / no      

 directory scan</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    

<font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org <hr noshade> <tt><font size=2>Hello, We will upgrade a pair of AFM cache nodes which serve about 40 SW filesets.

I want to do a rolling upgrade. I wonder if I can minimize the impact of

the failover when filesets move to the other afm node.  I can't stop

replication during the upgrade: The update will take too long (OS, mofed,

FW, scale) and we want to preserve the ability to recall files (?). Mostly

I want to avoid policy scans of all inodes on cache  (and maybe even

lookups of files on home??) <br>I can stop replication for a short time. Also the queues most of the time

are empty or contain just a few 100 entries. The cache filesets holds about

500M used inodes. Does a specific procedure exist, or is it good enough

to just shutdown scale on the node I want to update? And maybe flush the

queues first as  far as possible? <br><br>If a fileset has a zero length queue of pending transactions to home, will

this avoid any policy scan when a second afm node takes responsibility

for the fileset?<br><br>Maybe I did already ask this before. Unfortunately the manual isn't as

explicit as I would prefer when it talks about rolling upgrades.<br><br>Thank you,<br><br>Heiner<br><br>-- <br>=======================<br>Heinrich Billich<br>ETH Zürich<br>Informatikdienste<br>Tel.: +41 44 632 72 56<br>heinrich.billich@id.ethz.ch<br>========================<br> <br> <br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br><br></font></tt><br><br><BR>