<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" id="owaParaStyle">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hi Olaf,<br>
yes we have separate vdisks for MD: 2 vdisks, each is 100GBytes large, 1MBytes blocksize, 3WayReplication.<br>
<br>
&nbsp;&nbsp; A<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div id="divRpF683909" style="direction: ltr;"><font size="2" color="#000000" face="Tahoma"><b>From:</b> gpfsug-discuss-bounces@spectrumscale.org [gpfsug-discuss-bounces@spectrumscale.org] on behalf of Olaf Weiser [olaf.weiser@de.ibm.com]<br>
<b>Sent:</b> Thursday, November 16, 2017 1:03 PM<br>
<b>To:</b> gpfsug main discussion list<br>
<b>Subject:</b> Re: [gpfsug-discuss] Write performances and filesystem size<br>
</font><br>
</div>
<div></div>
<div><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%" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr valign="top">
<td style="width:96px" width="1%"><font size="2" color="#5F5F5F">Von:</font></td>
<td style="width:auto" width="100%"><font size="2">&quot;Ivano Talamo&quot; &lt;Ivano.Talamo@psi.ch&gt;</font></td>
</tr>
<tr valign="top">
<td style="width:96px" width="1%"><font size="2" color="#5F5F5F">An:</font></td>
<td style="width:auto" width="100%"><font size="2">&quot;gpfsug main discussion list&quot; &lt;gpfsug-discuss@spectrumscale.org&gt;</font></td>
</tr>
<tr valign="top">
<td style="width:96px" width="1%"><font size="2" color="#5F5F5F">Datum:</font></td>
<td style="width:auto" width="100%"><font size="2">Do. 16.11.2017 03:49</font></td>
</tr>
<tr valign="top">
<td style="width:96px" width="1%"><font size="2" color="#5F5F5F">Betreff:</font></td>
<td style="width:auto" width="100%"><font size="2">Re: [gpfsug-discuss] Write performances and filesystem size</font></td>
</tr>
</tbody>
</table>
<hr style="color:#8091A5" size="2" width="100%" noshade="" align="left">
<br>
</div>
<div style="">
<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;&quot;Jan-Frode Myklebust&quot; &lt;janfrode@tanso.net&gt;<br>&gt; An: &nbsp; &nbsp;&quot;gpfsug main discussion list&quot; &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;&quot;Kumaran Rajaram&quot; &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 &quot;-j<br>&gt; &nbsp; &nbsp; cluster&quot;.<br>&gt;<br>&gt; &nbsp; &nbsp; For consistent file-system performance, we recommend *mmcrfs &quot;-j<br>&gt; &nbsp; &nbsp; scatter&quot; layoutMap.* &nbsp; Also, we need to ensure the mmcrfs &quot;-n&quot; &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>
</div>
</div>
</div>
</div>
</body>
</html>