<font size=2 face="sans-serif">Doubtless there are subtleties and special
cases, but my should-work-well advice is:</font><br><br><font size=2 face="sans-serif">A) Use mmapplypolicy ... -I defer &nbsp;-P
policy-to-set-pool-assignments-and-replication-factor &nbsp;...</font><br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; where the policy
rules file contains rules like</font><br><br><font size=2 face="sans-serif">&nbsp; &nbsp; RULE 'adjust' MIGRATE
&nbsp;[FROM POOL 'x'] &nbsp;TO POOL 'y' &nbsp;REPLICATE({1|2}) &nbsp; WHERE
decide to which file this rule shall apply<br> </font><br><font size=2 face="sans-serif">&nbsp; &nbsp;The '-I defer' option says
just mark the inodes, do not actually move the data</font><br><br><font size=2 face="sans-serif">B) Use mmrestripefs ... &nbsp;-b &nbsp;...
-N nodeclass &nbsp; The move data to correct pool assignments and rebalance
the entire file system, also fix ill-replicated and ill-placed files. &nbsp;(keep
reading...)</font><br><br><font size=2 face="sans-serif">C) &quot;restripe only works within
the same pool&quot; &nbsp;-- I believe there is a misunderstanding. &nbsp;For
any given file, all the data blocks are supposed to be in the one pool
indicated by pool assignment which is recorded in the file's inode. &nbsp;If
the pool assignment changes but not all of the blocks are migrated to the
new pool, then the file is considered &quot;ill-placed&quot;. &nbsp;I believe
mmrestripefs endeavors to move blocks so as to &quot;fix&quot; ill-placed
files. &nbsp; Failure groups are a different concept that is associated
with replication. &nbsp;The replicas of a given data or meta data block
should be in different failure groups. &nbsp;If not, the file is considered
&quot;ill-replicated&quot; &nbsp;and mmrestripefs endeavors to fix that
also.</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">&quot;J. Eric Wonderley&quot;
&lt;eric.wonderley@vt.edu&gt;</font><br><font size=1 color=#5f5f5f face="sans-serif">To: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">gpfsug main discussion
list &lt;gpfsug-discuss@spectrumscale.org&gt;</font><br><font size=1 color=#5f5f5f face="sans-serif">Date: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">10/04/2016 09:39 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject: &nbsp; &nbsp;
&nbsp; &nbsp;</font><font size=1 face="sans-serif">[gpfsug-discuss]
migrate policy vs restripe</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by: &nbsp; &nbsp;
&nbsp; &nbsp;</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><font size=3>We have the need to move data from one set of spindles
to another.<br><br>Are there any performance or availability considerations when choosing
to do either a migration policy or a restripe to make this move?&nbsp;
I did discover that a restripe only works within the same pool...even though
you setup two pools in different failure groups.</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>