<HTML><BODY><FONT style='white-space:pre-wrap;font-family: Helvetica Neue, Helvetica, Arial, sans-serif;margin: 1em 0;'>Rjx, that makes it a bit clearer.. as&nbsp; your vdisk&nbsp; is big enough to span over all pdisks&nbsp; in each of your test 1/1 or 1/2 or 1/4&nbsp; of capacity... should bring the same performance. .. <br> <br>You mean something about vdisk Layout. .. <br>So in your test,&nbsp; for the full capacity test, you use just one vdisk per RG - so 2 in total for 'data' - right? <br> <br>What about Md .. did you create separate vdisk for MD&nbsp; / what size then ?&nbsp; &nbsp; <br><br>Gesendet von IBM Verse</FONT><br><br><div class="domino-section" dir="ltr"><div class="domino-section-head"><span class="domino-section-title"><font color="#424282">Ivano Talamo --- Re: [gpfsug-discuss] Write performances and filesystem size --- </font></span></div><div class="domino-section-body"><br><table width="100%" border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="1%" style="width: 96px;"><font size="2" color="#5F5F5F">Von:</font></td><td width="100%" style="width: auto;"><font size="2">&quot;Ivano Talamo&quot; &lt;Ivano.Talamo@psi.ch&gt;</font></td></tr><tr valign="top"><td width="1%" style="width: 96px;"><font size="2" color="#5F5F5F">An:</font></td><td width="100%" style="width: auto;"><font size="2">&quot;gpfsug main discussion list&quot; &lt;gpfsug-discuss@spectrumscale.org&gt;</font></td></tr><tr valign="top"><td width="1%" style="width: 96px;"><font size="2" color="#5F5F5F">Datum:</font></td><td width="100%" style="width: auto;"><font size="2">Do. 16.11.2017 03:49</font></td></tr><tr valign="top"><td width="1%" style="width: 96px;"><font size="2" color="#5F5F5F">Betreff:</font></td><td width="100%" style="width: auto;"><font size="2">Re: [gpfsug-discuss] Write performances and filesystem size</font></td></tr></table><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br></div><html><body><div style="opacity: 0,87;"><pre style="white-space:pre-wrap;"><font color="#000000">Hello Olaf,<br/><br/>yes, I confirm that is the Lenovo version of the ESS GL2, so 2 <br/>enclosures/4 drawers/166 disks in total.<br/><br/>Each recovery group has one declustered array with all disks inside, so <br/>vdisks use all the physical ones, even in the case of a vdisk that is <br/>1/4 of the total size.<br/><br/>Regarding the layout allocation we used scatter.<br/><br/>The tests were done on the just created filesystem, so no close-to-full <br/>effect. And we run gpfsperf write seq.<br/><br/>Thanks,<br/>Ivano<br/><br/><br/>Il 16/11/17 04:42, Olaf Weiser ha scritto:<br/><!-- -->&gt; Sure... as long we assume that really all physical disk are used .. the<br/><!-- -->&gt; fact that &nbsp;was told 1/2 &nbsp;or 1/4 &nbsp;might turn out that one / two complet<br/><!-- -->&gt; enclosures 're eliminated ... ? &nbsp;..that s why I was asking for &nbsp;more<br/><!-- -->&gt; details ..<br/><!-- -->&gt;<br/><!-- -->&gt; I dont see this degration in my environments. . as long the vdisks are<br/><!-- -->&gt; big enough to span over all pdisks ( which should be the case for<br/><!-- -->&gt; capacity in a range of TB ) ... the performance stays the same<br/><!-- -->&gt;<br/><!-- -->&gt; Gesendet von IBM Verse<br/><!-- -->&gt;<br/><!-- -->&gt; Jan-Frode Myklebust --- Re: [gpfsug-discuss] Write performances and<br/><!-- -->&gt; filesystem size ---<br/><!-- -->&gt;<br/><!-- -->&gt; Von: &nbsp; &nbsp;"Jan-Frode Myklebust" <!-- -->&lt;janfrode@tanso.net<!-- -->&gt;<br/><!-- -->&gt; An: &nbsp; &nbsp;"gpfsug main discussion list" <!-- -->&lt;gpfsug-discuss@spectrumscale.org<!-- -->&gt;<br/><!-- -->&gt; Datum: &nbsp; &nbsp;Mi. 15.11.2017 21:35<br/><!-- -->&gt; Betreff: &nbsp; &nbsp;Re: [gpfsug-discuss] Write performances and filesystem size<br/><!-- -->&gt;<br/><!-- -->&gt; ------------------------------------------------------------------------<br/><!-- -->&gt;<br/><!-- -->&gt; Olaf, this looks like a Lenovo «ESS GLxS» version. Should be using same<br/><!-- -->&gt; number of spindles for any size filesystem, so I would also expect them<br/><!-- -->&gt; to perform the same.<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt; -jf<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt; ons. 15. nov. 2017 kl. 11:26 skrev Olaf Weiser <!-- -->&lt;olaf.weiser@de.ibm.com<br/><!-- -->&gt; <!-- -->&lt;mailto:olaf.weiser@de.ibm.com<!-- -->&gt;<!-- -->&gt;:<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp;to add a comment ... &nbsp;.. very simply... depending on how you<br/><!-- -->&gt; &nbsp; &nbsp; allocate the physical block storage .... if you - simply - using<br/><!-- -->&gt; &nbsp; &nbsp; less physical resources when reducing the capacity (in the same<br/><!-- -->&gt; &nbsp; &nbsp; ratio) .. you get , what you see....<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; so you need to tell us, how you allocate your block-storage .. (Do<br/><!-- -->&gt; &nbsp; &nbsp; you using RAID controllers , where are your LUNs coming from, are<br/><!-- -->&gt; &nbsp; &nbsp; then less RAID groups involved, when reducing the capacity ?...)<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; GPFS can be configured to give you pretty as much as what the<br/><!-- -->&gt; &nbsp; &nbsp; hardware can deliver.. if you reduce resource.. ... you'll get less<br/><!-- -->&gt; &nbsp; &nbsp; , if you enhance your hardware .. you get more... almost regardless<br/><!-- -->&gt; &nbsp; &nbsp; of the total capacity in #blocks ..<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; From: &nbsp; &nbsp; &nbsp; &nbsp;"Kumaran Rajaram" <!-- -->&lt;kums@us.ibm.com<br/><!-- -->&gt; &nbsp; &nbsp; <!-- -->&lt;mailto:kums@us.ibm.com<!-- -->&gt;<!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;gpfsug main discussion list<br/><!-- -->&gt; &nbsp; &nbsp; <!-- -->&lt;gpfsug-discuss@spectrumscale.org<br/><!-- -->&gt; &nbsp; &nbsp; <!-- -->&lt;mailto:gpfsug-discuss@spectrumscale.org<!-- -->&gt;<!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; Date: &nbsp; &nbsp; &nbsp; &nbsp;11/15/2017 11:56 AM<br/><!-- -->&gt; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: [gpfsug-discuss] Write performances and<br/><!-- -->&gt; &nbsp; &nbsp; filesystem size<br/><!-- -->&gt; &nbsp; &nbsp; Sent by: &nbsp; &nbsp; &nbsp; &nbsp;gpfsug-discuss-bounces@spectrumscale.org<br/><!-- -->&gt; &nbsp; &nbsp; <!-- -->&lt;mailto:gpfsug-discuss-bounces@spectrumscale.org<!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; ------------------------------------------------------------------------<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; Hi,<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; <!-- -->&gt;<!-- -->&gt;Am I missing something? Is this an expected behaviour and someone<br/><!-- -->&gt; &nbsp; &nbsp; has an explanation for this?<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; Based on your scenario, write degradation as the file-system is<br/><!-- -->&gt; &nbsp; &nbsp; populated is possible if you had formatted the file-system with "-j<br/><!-- -->&gt; &nbsp; &nbsp; cluster".<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; For consistent file-system performance, we recommend *mmcrfs "-j<br/><!-- -->&gt; &nbsp; &nbsp; scatter" layoutMap.* &nbsp; Also, we need to ensure the mmcrfs "-n" &nbsp;is<br/><!-- -->&gt; &nbsp; &nbsp; set properly.<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; [snip from mmcrfs]/<br/><!-- -->&gt; &nbsp; &nbsp; # mmlsfs <!-- -->&lt;fs<!-- -->&gt; | egrep 'Block allocation| Estimated number'<br/><!-- -->&gt; &nbsp; &nbsp; -j &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; scatter &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Block allocation type<br/><!-- -->&gt; &nbsp; &nbsp; -n &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 128 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Estimated number of<br/><!-- -->&gt; &nbsp; &nbsp; nodes that will mount file system/<br/><!-- -->&gt; &nbsp; &nbsp; [/snip]<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; [snip from man mmcrfs]/<br/><!-- -->&gt; &nbsp; &nbsp; *layoutMap={scatter|*//*cluster}*//<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Specifies the block allocation map type. When<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;allocating blocks for a given file, GPFS first<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;uses a round\u2010robin algorithm to spread the data<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;across all disks in the storage pool. After a<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;disk is selected, the location of the data<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;block on the disk is determined by the block<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;allocation map type*. If cluster is<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;specified, GPFS attempts to allocate blocks in<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;clusters. Blocks that belong to a particular<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;file are kept adjacent to each other within<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;each cluster. If scatter is specified,<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the location of the block is chosen randomly.*/<br/><!-- -->&gt; &nbsp; &nbsp; /<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;* &nbsp;The cluster allocation method may provide<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;better disk performance for some disk<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;subsystems in relatively small installations.<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;The benefits of clustered block allocation<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;diminish when the number of nodes in the<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;cluster or the number of disks in a file system<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;increases, or when the file system\u2019s free space<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;becomes fragmented. *//The *cluster*//<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;allocation method is the default for GPFS<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;clusters with eight or fewer nodes and for file<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;systems with eight or fewer disks./<br/><!-- -->&gt; &nbsp; &nbsp; /<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; *The scatter allocation method provides<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;more consistent file system performance by<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;averaging out performance variations due to<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;block location (for many disk subsystems, the<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;location of the data relative to the disk edge<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;has a substantial effect on performance).*//This<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;allocation method is appropriate in most cases<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;and is the default for GPFS clusters with more<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;than eight nodes or file systems with more than<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;eight disks./<br/><!-- -->&gt; &nbsp; &nbsp; /<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;The block allocation map type cannot be changed<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;after the storage pool has been created./<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; */<br/><!-- -->&gt; &nbsp; &nbsp; -n/*/*NumNodes*//<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; The estimated number of nodes that will mount the file<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; system in the local cluster and all remote clusters.<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This is used as a best guess for the initial size of<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; some file system data structures. The default is 32.<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This value can be changed after the file system has been<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; created but it does not change the existing data<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; structures. Only the newly created data structure is<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; affected by the new value. For example, new storage<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pool./<br/><!-- -->&gt; &nbsp; &nbsp; /<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; When you create a GPFS file system, you might want to<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; overestimate the number of nodes that will mount the<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; file system. GPFS uses this information for creating<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; data structures that are essential for achieving maximum<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; parallelism in file system operations (For more<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; information, see GPFS architecture in IBM Spectrum<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Scale: Concepts, Planning, and Installation Guide ). If<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; you are sure there will never be more than 64 nodes,<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; allow the default value to be applied. If you are<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; planning to add nodes to your system, you should specify<br/><!-- -->&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a number larger than the default./<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; [/snip from man mmcrfs]<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; Regards,<br/><!-- -->&gt; &nbsp; &nbsp; -Kums<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; From: &nbsp; &nbsp; &nbsp; &nbsp;Ivano Talamo <!-- -->&lt;Ivano.Talamo@psi.ch<br/><!-- -->&gt; &nbsp; &nbsp; <!-- -->&lt;mailto:Ivano.Talamo@psi.ch<!-- -->&gt;<!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;<!-- -->&lt;gpfsug-discuss@spectrumscale.org<br/><!-- -->&gt; &nbsp; &nbsp; <!-- -->&lt;mailto:gpfsug-discuss@spectrumscale.org<!-- -->&gt;<!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; Date: &nbsp; &nbsp; &nbsp; &nbsp;11/15/2017 11:25 AM<br/><!-- -->&gt; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;[gpfsug-discuss] Write performances and filesystem size<br/><!-- -->&gt; &nbsp; &nbsp; Sent by: &nbsp; &nbsp; &nbsp; &nbsp;gpfsug-discuss-bounces@spectrumscale.org<br/><!-- -->&gt; &nbsp; &nbsp; <!-- -->&lt;mailto:gpfsug-discuss-bounces@spectrumscale.org<!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; ------------------------------------------------------------------------<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; Hello everybody,<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; together with my colleagues we are actually running some tests on a new<br/><!-- -->&gt; &nbsp; &nbsp; DSS G220 system and we see some unexpected behaviour.<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; What we actually see is that write performances (we did not test read<br/><!-- -->&gt; &nbsp; &nbsp; yet) decreases with the decrease of filesystem size.<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; I will not go into the details of the tests, but here are some numbers:<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; - with a filesystem using the full 1.2 PB space we get 14 GB/s as the<br/><!-- -->&gt; &nbsp; &nbsp; sum of the disk activity on the two IO servers;<br/><!-- -->&gt; &nbsp; &nbsp; - with a filesystem using half of the space we get 10 GB/s;<br/><!-- -->&gt; &nbsp; &nbsp; - with a filesystem using 1/4 of the space we get 5 GB/s.<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; We also saw that performances are not affected by the vdisks layout,<br/><!-- -->&gt; &nbsp; &nbsp; ie.<br/><!-- -->&gt; &nbsp; &nbsp; taking the full space with one big vdisk or 2 half-size vdisks per RG<br/><!-- -->&gt; &nbsp; &nbsp; gives the same performances.<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; To our understanding the IO should be spread evenly across all the<br/><!-- -->&gt; &nbsp; &nbsp; pdisks in the declustered array, and looking at iostat all disks<br/><!-- -->&gt; &nbsp; &nbsp; seem to<br/><!-- -->&gt; &nbsp; &nbsp; be accessed. But so there must be some other element that affects<br/><!-- -->&gt; &nbsp; &nbsp; performances.<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; Am I missing something? Is this an expected behaviour and someone<br/><!-- -->&gt; &nbsp; &nbsp; has an<br/><!-- -->&gt; &nbsp; &nbsp; explanation for this?<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; Thank you,<br/><!-- -->&gt; &nbsp; &nbsp; Ivano<br/><!-- -->&gt; &nbsp; &nbsp; _______________________________________________<br/><!-- -->&gt; &nbsp; &nbsp; gpfsug-discuss mailing list<br/><!-- -->&gt; &nbsp; &nbsp; gpfsug-discuss at spectrumscale.org <!-- -->&lt;http://spectrumscale.org<!-- -->&gt;_<br/><!-- -->&gt; &nbsp; &nbsp; __https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&amp;d=DwICAg&amp;c=jf_iaSHvJObTbx-siA1ZOg&amp;r=McIf98wfiVqHU8ZygezLrQ&amp;m=py_FGl3hi9yQsby94NZdpBFPwcUU0FREyMSSvuK_10U&amp;s=Bq1J9eIXxadn5yrjXPHmKEht0CDBwfKJNH72p--T-6s&amp;e=_<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; _______________________________________________<br/><!-- -->&gt; &nbsp; &nbsp; gpfsug-discuss mailing list<br/><!-- -->&gt; &nbsp; &nbsp; gpfsug-discuss at spectrumscale.org <!-- -->&lt;http://spectrumscale.org<!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; http://gpfsug.org/mailman/listinfo/gpfsug-discuss<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; _______________________________________________<br/><!-- -->&gt; &nbsp; &nbsp; gpfsug-discuss mailing list<br/><!-- -->&gt; &nbsp; &nbsp; gpfsug-discuss at spectrumscale.org <!-- -->&lt;http://spectrumscale.org<!-- -->&gt;<br/><!-- -->&gt; &nbsp; &nbsp; http://gpfsug.org/mailman/listinfo/gpfsug-discuss<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt;<br/><!-- -->&gt; _______________________________________________<br/><!-- -->&gt; gpfsug-discuss mailing list<br/><!-- -->&gt; gpfsug-discuss at spectrumscale.org<br/><!-- -->&gt; http://gpfsug.org/mailman/listinfo/gpfsug-discuss<br/><!-- -->&gt;<br/>_______________________________________________<br/>gpfsug-discuss mailing list<br/>gpfsug-discuss at spectrumscale.org<br/>http://gpfsug.org/mailman/listinfo/gpfsug-discuss<br/></font></pre></div><BR>
</body></html></BODY></HTML>