<font size=2 face="sans-serif">AFM based migration provides near-zero
downtime and supports migrating EAs/ACLs including immutability attributes
(if home is Scale/ESS). I would recommend starting migration in read-only
mode, prefetch most of the data and convert the fileset to local-updates
(if backup is not needed during the migration) or independent-writer mode
before moving the applications to the AFM cache filesets. AFM now supports
(from 5.0.2) directory level prefetch with many performance improvements
and does not require list-files to be specified.</font><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">"Oesterlin, Robert"
<Robert.Oesterlin@nuance.com></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">03/06/2019 06:14 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[gpfsug-discuss]
Follow-up: migrating billions of files</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><font size=2 face="Calibri">Some of you had questions to my original
post. More information:</font><br><font size=2 face="Calibri"> </font><br><font size=2 face="Calibri">Source:</font><br><font size=2 face="Calibri">- Files are straight GPFS/Posix - no extended
NFSV4 ACLs</font><br><font size=2 face="Calibri">- A solution that requires $’s to be spent
on software (ie, Aspera) isn’t a very viable option</font><br><font size=2 face="Calibri">- Both source and target clusters are in
the same DC</font><br><font size=2 face="Calibri">- Source is stand-alone NSD servers (bonded
10g-E) and 8gb FC SAN storage</font><br><font size=2 face="Calibri">- Approx 40 file systems, a few large ones
with 300M-400M files each, others smaller</font><br><font size=2 face="Calibri">- no independent file sets</font><br><font size=2 face="Calibri">- migration must pose minimal disruption
to existing users</font><br><font size=2 face="Calibri"> </font><br><font size=2 face="Calibri">Target architecture is a small number of
file systems (2-3) on ESS with independent filesets</font><br><font size=2 face="Calibri">- Target (ESS) will have multiple 40gb-E
links on each NSD server (GS4)</font><br><font size=2 face="Calibri"> </font><br><font size=2 face="Calibri">My current thinking is AFM with a pre-populate
of the file space and switch the clients over to have them pull data they
need (most of the data is older and less active) and them let AFM populate
the rest in the background.</font><br><font size=2 face="Calibri"> </font><br><font size=2 face="Calibri"> </font><br><font size=3 face="Calibri">Bob Oesterlin</font><br><font size=3 face="Calibri">Sr Principal Storage Engineer, Nuance</font><br><font size=3 face="Calibri"> </font><tt><font size=2>_______________________________________________<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></font></tt><br><br><BR>