<font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">cluster will also be there for some
time, as soon as one start deleting and creating file - it will kind of
shift to be scattered...</font>
<br><font size=2 face="sans-serif">So, while its good for benchmarks on
"clean and new" system - cluster is somewhat meaningless ( and
was hidden for some time because of that).</font>
<br>
<br><font size=2 face="sans-serif">As far as it goes for copying from old
to new system - AFM can be considered as well ( will make the transition
easier). You can prefetch ( using mmafmctl) and even work in LU mode in
order to get the data from the old FS to the new one without pushing changes
back.</font>
<br>
<br><font size=2 face="sans-serif">hth,</font>
<br><font size=2 face="sans-serif">Tomer.</font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Alex Chekholko <chekh@stanford.edu></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">gpfsug-discuss@gpfsug.org,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">10/30/2013 07:57 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Moving/copying files from one file system to another</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">gpfsug-discuss-bounces@gpfsug.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 10/30/13, 5:47 AM, Jonathan Buzzard wrote:<br>
> On Mon, 2013-10-28 at 11:31 -0400, Richard Lefebvre wrote:<br>
><br>
> [SNIP]<br>
><br>
>> Also, another question, under what condition a scatter allocation
better<br>
>> then cluster allocation. We currently have a cluster of 650 nodes
all<br>
>> accessing the same 230TB gpfs file system.<br>
>><br>
><br>
> Scatter allocation is better in almost all circumstances. Basically
by<br>
> scattering the files to all corners you don't get hotspots where just
a<br>
> small subset of the disks are being hammered by lots of accesses to
a<br>
> handful of files, while the rest of the disks sit idle.<br>
><br>
<br>
If you do benchmarks with only a few threads, you will see higher <br>
performance with 'cluster' allocation.  So if your workload is only
a <br>
few clients accessing the FS in a mostly streaming way, you'd see better
<br>
performance from 'cluster'.<br>
<br>
With 650 nodes, even if each client is doing streaming reads, at the <br>
filesystem level that would all be interleaved and thus be random reads.
<br>
  But it's tough to do a big enough benchmark to show the difference
in <br>
performance.<br>
<br>
I had a tough time convincing people to use 'scatter' instead of <br>
'cluster' even though I think the documentation is clear about the <br>
difference, and even gives you the sizing parameters ( greater than 8 <br>
disks or 8 NSDs?  use 'scatter').<br>
<br>
We use 'scatter' now.<br>
<br>
Regards<br>
-- <br>
chekh@stanford.edu<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at gpfsug.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>