text: If the grain is larger than most host writes, this issue can lead to write amplification on the 
  target system. This increase is because for every write IO to an unsplit grain, the whole 
  grain must be read from the FlashCopy source and copied to the target. Such a situation 
  might result in performance degradation. 
  
  If a thin-provisioned volume is used in a FlashCopy map, use the same grain size as the 
  map grain size for best performance. Also, if a thin-provisioned volume is used directly 
  with a host system, use a grain size that more closely matches the host IO size. 
  
  (cid:2) Define which FlashCopy rate best fits your requirement in terms of the storage 
  
  performance and the amount of time required to complete the FlashCopy. Table 3-4 lists 
  the relationship of the background copy rate value to the number of grain split attempts per 
  second. 
  
  For performance-sensitive configurations, test the performance observed for different 
  settings of grain size and FlashCopy rate in your actual environment before committing a 
  solution to production use. See Table 3-4 for some baseline data. 
  
  Table 3-4 Grain splits per second 
  
  <html>
          <head> <meta charset="UTF-8">
          <style>
          table, th, td {
              border: 1px solid black;
              font-size: 10px;
          }
          </style> </head>
          <body>
          <table frame="hsides" rules="groups" width="100%%">
              [html]<thead><tr><td>User percentage</td><td>Data copied per second</td><td>256 KiB grain per second</td><td>64 KiB grain per second</td></tr></thead><tbody><tr><td>1 - 10</td><td>128 KiB</td><td>0.5</td><td>2</td></tr><tr><td>11 - 20</td><td>256 KiB</td><td>1</td><td>4</td></tr><tr><td>21 - 30</td><td>512 KiB</td><td>2</td><td>8</td></tr></tbody>
          </table> </body> </html>