<font size=2 face="sans-serif">Hi Ivano, </font><br><font size=2 face="sans-serif">so from this output, the performance
degradation is not explainable .. </font><br><font size=2 face="sans-serif">in my current environments.. , having
multiple file systems (so vdisks on one BB) .. and it works fine .. </font><br><br><font size=2 face="sans-serif">&nbsp;as said .. just open a PMR.. I
would'nt consider this as the &quot;expected behavior&quot; </font><br><div><font size=2 face="sans-serif">the only thing is.. the MD disks are
a bit small.. so maybe redo your tests and for a simple compare between
1/2 1/1 or 1/4 capacity &nbsp;test with 2 vdisks only and <i>dataAndMetadata</i></font><br><font size=2 face="sans-serif">cheers</font><br><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">Ivano Talamo &lt;Ivano.Talamo@psi.ch&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">11/16/2017 08:52 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject: &nbsp; &nbsp;
&nbsp; &nbsp;</font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Write performances and filesystem size</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><tt><font size=2>Hi,<br><br>as additional information I past the recovery group information in the
<br>full and half size cases.<br>In both cases:<br>- data is on sf_g_01_vdisk01<br>- metadata on sf_g_01_vdisk02<br>- sf_g_01_vdisk07 is not used in the filesystem.<br><br>This is with the full-space filesystem:<br><br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
declustered &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; current &nbsp; &nbsp; &nbsp; allowable<br> &nbsp;recovery group &nbsp; &nbsp; &nbsp; arrays &nbsp; &nbsp; vdisks
&nbsp;pdisks &nbsp;format version format <br>version<br> &nbsp;----------------- &nbsp;----------- &nbsp;------ &nbsp;------ &nbsp;--------------
<br>--------------<br> &nbsp;sf-g-01 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;3 &nbsp; &nbsp; &nbsp; 6 &nbsp; &nbsp; &nbsp;86 &nbsp;4.2.2.0
&nbsp; &nbsp; &nbsp; &nbsp;4.2.2.0 <br><br><br> &nbsp;declustered &nbsp; needs &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;replace <br>scrub &nbsp; &nbsp; &nbsp; background activity<br> &nbsp; &nbsp; array &nbsp; &nbsp; service &nbsp;vdisks &nbsp;pdisks &nbsp;spares
&nbsp;threshold &nbsp;free space <br>duration &nbsp;task &nbsp; progress &nbsp;priority<br> &nbsp;----------- &nbsp;------- &nbsp;------ &nbsp;------ &nbsp;------
&nbsp;--------- &nbsp;---------- <br>-------- &nbsp;-------------------------<br> &nbsp;NVR &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;no &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp; &nbsp; 2 &nbsp; &nbsp; 0,0 &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp;3632 MiB <br>14 days &nbsp;scrub &nbsp; &nbsp; &nbsp; 95% &nbsp;low<br> &nbsp;DA1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;no &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;4 &nbsp; &nbsp; &nbsp;83 &nbsp; &nbsp;2,44 &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp; &nbsp;57 TiB <br>14 days &nbsp;scrub &nbsp; &nbsp; &nbsp; &nbsp;0% &nbsp;low<br> &nbsp;SSD &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;no &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp; &nbsp; 1 &nbsp; &nbsp; 0,0 &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp; 372 GiB <br>14 days &nbsp;scrub &nbsp; &nbsp; &nbsp; 79% &nbsp;low<br><br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;declustered
<br> &nbsp; &nbsp; &nbsp; &nbsp;checksum<br> &nbsp;vdisk &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; RAID code
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;array &nbsp; &nbsp; vdisk
size &nbsp;block <br>size &nbsp;granularity &nbsp;state remarks<br> &nbsp;------------------ &nbsp;------------------ &nbsp;----------- &nbsp;----------
<br>---------- &nbsp;----------- &nbsp;----- -------<br> &nbsp;sf_g_01_logTip &nbsp; &nbsp; &nbsp;2WayReplication &nbsp; &nbsp;
NVR &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;48 MiB &nbsp; &nbsp;
&nbsp;2 <br>MiB &nbsp; &nbsp; &nbsp;4096 &nbsp; &nbsp; &nbsp;ok &nbsp; &nbsp;logTip<br> &nbsp;sf_g_01_logTipBackup &nbsp;Unreplicated &nbsp; &nbsp; &nbsp; &nbsp;SSD
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;48 MiB <br>2 MiB &nbsp; &nbsp; &nbsp;4096 &nbsp; &nbsp; &nbsp;ok &nbsp; &nbsp;logTipBackup<br> &nbsp;sf_g_01_logHome &nbsp; &nbsp; 4WayReplication &nbsp; &nbsp; DA1
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 144 GiB &nbsp; &nbsp; &nbsp;2
<br>MiB &nbsp; &nbsp; &nbsp;4096 &nbsp; &nbsp; &nbsp;ok &nbsp; &nbsp;log<br> &nbsp;sf_g_01_vdisk02 &nbsp; &nbsp; 3WayReplication &nbsp; &nbsp; DA1
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 103 GiB &nbsp; &nbsp; &nbsp;1
<br>MiB &nbsp; &nbsp; 32 KiB &nbsp; &nbsp; ok<br> &nbsp;sf_g_01_vdisk07 &nbsp; &nbsp; 3WayReplication &nbsp; &nbsp; DA1
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 103 GiB &nbsp; &nbsp; &nbsp;1
<br>MiB &nbsp; &nbsp; 32 KiB &nbsp; &nbsp; ok<br> &nbsp;sf_g_01_vdisk01 &nbsp; &nbsp; 8+2p &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;DA1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 540 TiB
&nbsp; &nbsp; 16 <br>MiB &nbsp; &nbsp; 32 KiB &nbsp; &nbsp; ok<br><br> &nbsp;config data &nbsp; &nbsp; &nbsp; &nbsp; declustered array &nbsp;
spare space &nbsp; &nbsp;remarks<br> &nbsp;------------------ &nbsp;------------------ &nbsp;-------------
&nbsp;-------<br> &nbsp;rebuild space &nbsp; &nbsp; &nbsp; DA1 &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; 53 pdisk <br> &nbsp; &nbsp; increasing VCD spares is suggested<br><br> &nbsp;config data &nbsp; &nbsp; &nbsp; &nbsp; disk group fault tolerance
&nbsp; &nbsp; &nbsp; &nbsp; remarks<br> &nbsp;------------------ &nbsp;--------------------------------- &nbsp;-------<br> &nbsp;rg descriptor &nbsp; &nbsp; &nbsp; 1 enclosure + 1 drawer + 2 pdisk
&nbsp; limited by <br>rebuild space<br> &nbsp;system index &nbsp; &nbsp; &nbsp; &nbsp;1 enclosure + 1 drawer +
2 pdisk &nbsp; limited by <br>rebuild space<br><br> &nbsp;vdisk &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; disk group
fault tolerance &nbsp; &nbsp; &nbsp; &nbsp; remarks<br> &nbsp;------------------ &nbsp;--------------------------------- &nbsp;-------<br> &nbsp;sf_g_01_logTip &nbsp; &nbsp; &nbsp;1 pdisk<br> &nbsp;sf_g_01_logTipBackup &nbsp;0 pdisk<br> &nbsp;sf_g_01_logHome &nbsp; &nbsp; 1 enclosure + 1 drawer + 1 pdisk &nbsp;
limited by <br>rebuild space<br> &nbsp;sf_g_01_vdisk02 &nbsp; &nbsp; 1 enclosure + 1 drawer &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; limited by <br>rebuild space<br> &nbsp;sf_g_01_vdisk07 &nbsp; &nbsp; 1 enclosure + 1 drawer &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; limited by <br>rebuild space<br> &nbsp;sf_g_01_vdisk01 &nbsp; &nbsp; 2 pdisk<br><br><br>This is with the half-space filesystem:<br><br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
declustered &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; current &nbsp; &nbsp; &nbsp; allowable<br> &nbsp;recovery group &nbsp; &nbsp; &nbsp; arrays &nbsp; &nbsp; vdisks
&nbsp;pdisks &nbsp;format version format <br>version<br> &nbsp;----------------- &nbsp;----------- &nbsp;------ &nbsp;------ &nbsp;--------------
<br>--------------<br> &nbsp;sf-g-01 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;3 &nbsp; &nbsp; &nbsp; 6 &nbsp; &nbsp; &nbsp;86 &nbsp;4.2.2.0
&nbsp; &nbsp; &nbsp; &nbsp;4.2.2.0 <br><br><br> &nbsp;declustered &nbsp; needs &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;replace <br>scrub &nbsp; &nbsp; &nbsp; background activity<br> &nbsp; &nbsp; array &nbsp; &nbsp; service &nbsp;vdisks &nbsp;pdisks &nbsp;spares
&nbsp;threshold &nbsp;free space <br>duration &nbsp;task &nbsp; progress &nbsp;priority<br> &nbsp;----------- &nbsp;------- &nbsp;------ &nbsp;------ &nbsp;------
&nbsp;--------- &nbsp;---------- <br>-------- &nbsp;-------------------------<br> &nbsp;NVR &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;no &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp; &nbsp; 2 &nbsp; &nbsp; 0,0 &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp;3632 MiB <br>14 days &nbsp;scrub &nbsp; &nbsp; &nbsp; &nbsp;4% &nbsp;low<br> &nbsp;DA1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;no &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;4 &nbsp; &nbsp; &nbsp;83 &nbsp; &nbsp;2,44 &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp; 395 TiB <br>14 days &nbsp;scrub &nbsp; &nbsp; &nbsp; &nbsp;0% &nbsp;low<br> &nbsp;SSD &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;no &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp; &nbsp; 1 &nbsp; &nbsp; 0,0 &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;1 &nbsp; &nbsp; 372 GiB <br>14 days &nbsp;scrub &nbsp; &nbsp; &nbsp; 79% &nbsp;low<br><br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;declustered
<br> &nbsp; &nbsp; &nbsp; &nbsp;checksum<br> &nbsp;vdisk &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; RAID code
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;array &nbsp; &nbsp; vdisk
size &nbsp;block <br>size &nbsp;granularity &nbsp;state remarks<br> &nbsp;------------------ &nbsp;------------------ &nbsp;----------- &nbsp;----------
<br>---------- &nbsp;----------- &nbsp;----- -------<br> &nbsp;sf_g_01_logTip &nbsp; &nbsp; &nbsp;2WayReplication &nbsp; &nbsp;
NVR &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;48 MiB &nbsp; &nbsp;
&nbsp;2 <br>MiB &nbsp; &nbsp; &nbsp;4096 &nbsp; &nbsp; &nbsp;ok &nbsp; &nbsp;logTip<br> &nbsp;sf_g_01_logTipBackup &nbsp;Unreplicated &nbsp; &nbsp; &nbsp; &nbsp;SSD
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;48 MiB <br>2 MiB &nbsp; &nbsp; &nbsp;4096 &nbsp; &nbsp; &nbsp;ok &nbsp; &nbsp;logTipBackup<br> &nbsp;sf_g_01_logHome &nbsp; &nbsp; 4WayReplication &nbsp; &nbsp; DA1
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 144 GiB &nbsp; &nbsp; &nbsp;2
<br>MiB &nbsp; &nbsp; &nbsp;4096 &nbsp; &nbsp; &nbsp;ok &nbsp; &nbsp;log<br> &nbsp;sf_g_01_vdisk02 &nbsp; &nbsp; 3WayReplication &nbsp; &nbsp; DA1
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 103 GiB &nbsp; &nbsp; &nbsp;1
<br>MiB &nbsp; &nbsp; 32 KiB &nbsp; &nbsp; ok<br> &nbsp;sf_g_01_vdisk07 &nbsp; &nbsp; 3WayReplication &nbsp; &nbsp; DA1
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 103 GiB &nbsp; &nbsp; &nbsp;1
<br>MiB &nbsp; &nbsp; 32 KiB &nbsp; &nbsp; ok<br> &nbsp;sf_g_01_vdisk01 &nbsp; &nbsp; 8+2p &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;DA1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 270 TiB
&nbsp; &nbsp; 16 <br>MiB &nbsp; &nbsp; 32 KiB &nbsp; &nbsp; ok<br><br> &nbsp;config data &nbsp; &nbsp; &nbsp; &nbsp; declustered array &nbsp;
spare space &nbsp; &nbsp;remarks<br> &nbsp;------------------ &nbsp;------------------ &nbsp;-------------
&nbsp;-------<br> &nbsp;rebuild space &nbsp; &nbsp; &nbsp; DA1 &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; 68 pdisk <br> &nbsp; &nbsp; increasing VCD spares is suggested<br><br> &nbsp;config data &nbsp; &nbsp; &nbsp; &nbsp; disk group fault tolerance
&nbsp; &nbsp; &nbsp; &nbsp; remarks<br> &nbsp;------------------ &nbsp;--------------------------------- &nbsp;-------<br> &nbsp;rg descriptor &nbsp; &nbsp; &nbsp; 1 node + 3 pdisk &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; limited by <br>rebuild space<br> &nbsp;system index &nbsp; &nbsp; &nbsp; &nbsp;1 node + 3 pdisk &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; limited by <br>rebuild space<br><br> &nbsp;vdisk &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; disk group
fault tolerance &nbsp; &nbsp; &nbsp; &nbsp; remarks<br> &nbsp;------------------ &nbsp;--------------------------------- &nbsp;-------<br> &nbsp;sf_g_01_logTip &nbsp; &nbsp; &nbsp;1 pdisk<br> &nbsp;sf_g_01_logTipBackup &nbsp;0 pdisk<br> &nbsp;sf_g_01_logHome &nbsp; &nbsp; 1 node + 2 pdisk &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; limited by <br>rebuild space<br> &nbsp;sf_g_01_vdisk02 &nbsp; &nbsp; 1 node + 1 pdisk &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; limited by <br>rebuild space<br> &nbsp;sf_g_01_vdisk07 &nbsp; &nbsp; 1 node + 1 pdisk &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; limited by <br>rebuild space<br> &nbsp;sf_g_01_vdisk01 &nbsp; &nbsp; 2 pdisk<br><br><br>Thanks,<br>Ivano<br><br><br><br><br>Il 16/11/17 13:03, Olaf Weiser ha scritto:<br>&gt; Rjx, that makes it a bit clearer.. as &nbsp;your vdisk &nbsp;is big
enough to span<br>&gt; over all pdisks &nbsp;in each of your test 1/1 or 1/2 or 1/4 &nbsp;of
capacity...<br>&gt; should bring the same performance. ..<br>&gt;<br>&gt; You mean something about vdisk Layout. ..<br>&gt; So in your test, &nbsp;for the full capacity test, you use just one
vdisk per<br>&gt; RG - so 2 in total for 'data' - right?<br>&gt;<br>&gt; What about Md .. did you create separate vdisk for MD &nbsp;/ what
size then<br>&gt; ?<br>&gt;<br>&gt; Gesendet von IBM Verse<br>&gt;<br>&gt; Ivano Talamo --- Re: [gpfsug-discuss] Write performances and filesystem<br>&gt; size ---<br>&gt;<br>&gt; Von: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&quot;Ivano Talamo&quot; &lt;Ivano.Talamo@psi.ch&gt;<br>&gt; An: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&quot;gpfsug main discussion list&quot; &lt;gpfsug-discuss@spectrumscale.org&gt;<br>&gt; Datum: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
Do. 16.11.2017 03:49<br>&gt; Betreff: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; Re: [gpfsug-discuss] Write performances and filesystem size<br>&gt;<br>&gt; ------------------------------------------------------------------------<br>&gt;<br>&gt; Hello Olaf,<br>&gt;<br>&gt; yes, I confirm that is the Lenovo version of the ESS GL2, so 2<br>&gt; enclosures/4 drawers/166 disks in total.<br>&gt;<br>&gt; Each recovery group has one declustered array with all disks inside,
so<br>&gt; vdisks use all the physical ones, even in the case of a vdisk that
is<br>&gt; 1/4 of the total size.<br>&gt;<br>&gt; Regarding the layout allocation we used scatter.<br>&gt;<br>&gt; The tests were done on the just created filesystem, so no close-to-full<br>&gt; effect. And we run gpfsperf write seq.<br>&gt;<br>&gt; Thanks,<br>&gt; Ivano<br>&gt;<br>&gt;<br>&gt; Il 16/11/17 04:42, Olaf Weiser ha scritto:<br>&gt;&gt; Sure... as long we assume that really all physical disk are used
.. the<br>&gt;&gt; fact that &nbsp;was told 1/2 &nbsp;or 1/4 &nbsp;might turn out
that one / two complet<br>&gt;&gt; enclosures 're eliminated ... ? &nbsp;..that s why I was asking
for &nbsp;more<br>&gt;&gt; details ..<br>&gt;&gt;<br>&gt;&gt; I dont see this degration in my environments. . as long the vdisks
are<br>&gt;&gt; big enough to span over all pdisks ( which should be the case
for<br>&gt;&gt; capacity in a range of TB ) ... the performance stays the same<br>&gt;&gt;<br>&gt;&gt; Gesendet von IBM Verse<br>&gt;&gt;<br>&gt;&gt; Jan-Frode Myklebust --- Re: [gpfsug-discuss] Write performances
and<br>&gt;&gt; filesystem size ---<br>&gt;&gt;<br>&gt;&gt; Von: &nbsp; &nbsp;&quot;Jan-Frode Myklebust&quot; &lt;janfrode@tanso.net&gt;<br>&gt;&gt; An: &nbsp; &nbsp;&quot;gpfsug main discussion list&quot; &lt;gpfsug-discuss@spectrumscale.org&gt;<br>&gt;&gt; Datum: &nbsp; &nbsp;Mi. 15.11.2017 21:35<br>&gt;&gt; Betreff: &nbsp; &nbsp;Re: [gpfsug-discuss] Write performances
and filesystem size<br>&gt;&gt;<br>&gt;&gt; ------------------------------------------------------------------------<br>&gt;&gt;<br>&gt;&gt; Olaf, this looks like a Lenovo ESS GLxS version. Should be using
same<br>&gt;&gt; number of spindles for any size filesystem, so I would also expect
them<br>&gt;&gt; to perform the same.<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; -jf<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; ons. 15. nov. 2017 kl. 11:26 skrev Olaf Weiser &lt;olaf.weiser@de.ibm.com<br>&gt;&gt; &lt;</font></tt><a href=mailto:olaf.weiser@de.ibm.com><tt><font size=2>mailto:olaf.weiser@de.ibm.com</font></tt></a><tt><font size=2>&gt;&gt;:<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; &nbsp;to add a comment ... &nbsp;.. very simply...
depending on how you<br>&gt;&gt; &nbsp; &nbsp; allocate the physical block storage .... if you
- simply - using<br>&gt;&gt; &nbsp; &nbsp; less physical resources when reducing the capacity
(in the same<br>&gt;&gt; &nbsp; &nbsp; ratio) .. you get , what you see....<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; so you need to tell us, how you allocate your block-storage
.. (Do<br>&gt;&gt; &nbsp; &nbsp; you using RAID controllers , where are your LUNs
coming from, are<br>&gt;&gt; &nbsp; &nbsp; then less RAID groups involved, when reducing the
capacity ?...)<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; GPFS can be configured to give you pretty as much
as what the<br>&gt;&gt; &nbsp; &nbsp; hardware can deliver.. if you reduce resource..
... you'll get less<br>&gt;&gt; &nbsp; &nbsp; , if you enhance your hardware .. you get more...
almost regardless<br>&gt;&gt; &nbsp; &nbsp; of the total capacity in #blocks ..<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; From: &nbsp; &nbsp; &nbsp; &nbsp;&quot;Kumaran Rajaram&quot;
&lt;kums@us.ibm.com<br>&gt;&gt; &nbsp; &nbsp; &lt;</font></tt><a href=mailto:kums@us.ibm.com><tt><font size=2>mailto:kums@us.ibm.com</font></tt></a><tt><font size=2>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;gpfsug main discussion
list<br>&gt;&gt; &nbsp; &nbsp; &lt;gpfsug-discuss@spectrumscale.org<br>&gt;&gt; &nbsp; &nbsp; &lt;</font></tt><a href="mailto:gpfsug-discuss@spectrumscale.org"><tt><font size=2>mailto:gpfsug-discuss@spectrumscale.org</font></tt></a><tt><font size=2>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; Date: &nbsp; &nbsp; &nbsp; &nbsp;11/15/2017 11:56
AM<br>&gt;&gt; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: [gpfsug-discuss]
Write performances and<br>&gt;&gt; &nbsp; &nbsp; filesystem size<br>&gt;&gt; &nbsp; &nbsp; Sent by: &nbsp; &nbsp; &nbsp; &nbsp;gpfsug-discuss-bounces@spectrumscale.org<br>&gt;&gt; &nbsp; &nbsp; &lt;</font></tt><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org"><tt><font size=2>mailto:gpfsug-discuss-bounces@spectrumscale.org</font></tt></a><tt><font size=2>&gt;<br>&gt;&gt;<br>&gt; ------------------------------------------------------------------------<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; Hi,<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; &gt;&gt;Am I missing something? Is this an expected
behaviour and someone<br>&gt;&gt; &nbsp; &nbsp; has an explanation for this?<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; Based on your scenario, write degradation as the
file-system is<br>&gt;&gt; &nbsp; &nbsp; populated is possible if you had formatted the file-system
with &quot;-j<br>&gt;&gt; &nbsp; &nbsp; cluster&quot;.<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; For consistent file-system performance, we recommend
*mmcrfs &quot;-j<br>&gt;&gt; &nbsp; &nbsp; scatter&quot; layoutMap.* &nbsp; Also, we need to
ensure the mmcrfs &quot;-n&quot; &nbsp;is<br>&gt;&gt; &nbsp; &nbsp; set properly.<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; [snip from mmcrfs]/<br>&gt;&gt; &nbsp; &nbsp; # mmlsfs &lt;fs&gt; | egrep 'Block allocation| Estimated
number'<br>&gt;&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;&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;&gt; &nbsp; &nbsp; nodes that will mount file system/<br>&gt;&gt; &nbsp; &nbsp; [/snip]<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; [snip from man mmcrfs]/<br>&gt;&gt; &nbsp; &nbsp; *layoutMap={scatter|*//*cluster}*//<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;Specifies the block allocation map type. When<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;allocating blocks for a given file, GPFS first<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;uses a round&#8208;robin algorithm to spread the data<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;across all disks in the storage pool. After a<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;disk is selected, the location of the data<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;block on the disk is determined by the block<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;allocation map type*. If cluster is<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;specified, GPFS attempts to allocate blocks in<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;clusters. Blocks that belong to a particular<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;file are kept adjacent to each other within<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;each cluster. If scatter is specified,<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;the location of the block is chosen randomly.*/<br>&gt;&gt; &nbsp; &nbsp; /<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;*
&nbsp;The cluster allocation method may provide<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;better disk performance for some disk<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;subsystems in relatively small installations.<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;The benefits of clustered block allocation<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;diminish when the number of nodes in the<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;cluster or the number of disks in a file system<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;increases, or when the file system&#8217;s free space<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;becomes fragmented. *//The *cluster*//<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;allocation method is the default for GPFS<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;clusters with eight or fewer nodes and for file<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;systems with eight or fewer disks./<br>&gt;&gt; &nbsp; &nbsp; /<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; *The scatter allocation method provides<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;more consistent file system performance by<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;averaging out performance variations due to<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;block location (for many disk subsystems, the<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;location of the data relative to the disk edge<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;has a substantial effect on performance).*//This<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;allocation method is appropriate in most cases<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;and is the default for GPFS clusters with more<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;than eight nodes or file systems with more than<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;eight disks./<br>&gt;&gt; &nbsp; &nbsp; /<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;The block allocation map type cannot be changed<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;after the storage pool has been created./<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; */<br>&gt;&gt; &nbsp; &nbsp; -n/*/*NumNodes*//<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; The estimated number
of nodes that will mount the file<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; system in the local
cluster and all remote clusters.<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This is used as a best
guess for the initial size of<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; some file system data
structures. The default is 32.<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This value can be changed
after the file system has been<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; created but it does
not change the existing data<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; structures. Only the
newly created data structure is<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; affected by the new
value. For example, new storage<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pool./<br>&gt;&gt; &nbsp; &nbsp; /<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; When you create a GPFS
file system, you might want to<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; overestimate the number
of nodes that will mount the<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; file system. GPFS uses
this information for creating<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; data structures that
are essential for achieving maximum<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; parallelism in file
system operations (For more<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; information, see GPFS
architecture in IBM Spectrum<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Scale: Concepts, Planning,
and Installation Guide ). If<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; you are sure there will
never be more than 64 nodes,<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; allow the default value
to be applied. If you are<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; planning to add nodes
to your system, you should specify<br>&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a number larger than
the default./<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; [/snip from man mmcrfs]<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; Regards,<br>&gt;&gt; &nbsp; &nbsp; -Kums<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; From: &nbsp; &nbsp; &nbsp; &nbsp;Ivano Talamo &lt;Ivano.Talamo@psi.ch<br>&gt;&gt; &nbsp; &nbsp; &lt;</font></tt><a href=mailto:Ivano.Talamo@psi.ch><tt><font size=2>mailto:Ivano.Talamo@psi.ch</font></tt></a><tt><font size=2>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&lt;gpfsug-discuss@spectrumscale.org<br>&gt;&gt; &nbsp; &nbsp; &lt;</font></tt><a href="mailto:gpfsug-discuss@spectrumscale.org"><tt><font size=2>mailto:gpfsug-discuss@spectrumscale.org</font></tt></a><tt><font size=2>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; Date: &nbsp; &nbsp; &nbsp; &nbsp;11/15/2017 11:25
AM<br>&gt;&gt; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;[gpfsug-discuss]
Write performances and filesystem<br>&gt; size<br>&gt;&gt; &nbsp; &nbsp; Sent by: &nbsp; &nbsp; &nbsp; &nbsp;gpfsug-discuss-bounces@spectrumscale.org<br>&gt;&gt; &nbsp; &nbsp; &lt;</font></tt><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org"><tt><font size=2>mailto:gpfsug-discuss-bounces@spectrumscale.org</font></tt></a><tt><font size=2>&gt;<br>&gt;&gt;<br>&gt; ------------------------------------------------------------------------<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; Hello everybody,<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; together with my colleagues we are actually running
some tests on<br>&gt; a new<br>&gt;&gt; &nbsp; &nbsp; DSS G220 system and we see some unexpected behaviour.<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; What we actually see is that write performances
(we did not test read<br>&gt;&gt; &nbsp; &nbsp; yet) decreases with the decrease of filesystem size.<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; I will not go into the details of the tests, but
here are some<br>&gt; numbers:<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; - with a filesystem using the full 1.2 PB space
we get 14 GB/s as the<br>&gt;&gt; &nbsp; &nbsp; sum of the disk activity on the two IO servers;<br>&gt;&gt; &nbsp; &nbsp; - with a filesystem using half of the space we get
10 GB/s;<br>&gt;&gt; &nbsp; &nbsp; - with a filesystem using 1/4 of the space we get
5 GB/s.<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; We also saw that performances are not affected by
the vdisks layout,<br>&gt;&gt; &nbsp; &nbsp; ie.<br>&gt;&gt; &nbsp; &nbsp; taking the full space with one big vdisk or 2 half-size
vdisks per RG<br>&gt;&gt; &nbsp; &nbsp; gives the same performances.<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; To our understanding the IO should be spread evenly
across all the<br>&gt;&gt; &nbsp; &nbsp; pdisks in the declustered array, and looking at
iostat all disks<br>&gt;&gt; &nbsp; &nbsp; seem to<br>&gt;&gt; &nbsp; &nbsp; be accessed. But so there must be some other element
that affects<br>&gt;&gt; &nbsp; &nbsp; performances.<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; Am I missing something? Is this an expected behaviour
and someone<br>&gt;&gt; &nbsp; &nbsp; has an<br>&gt;&gt; &nbsp; &nbsp; explanation for this?<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; Thank you,<br>&gt;&gt; &nbsp; &nbsp; Ivano<br>&gt;&gt; &nbsp; &nbsp; _______________________________________________<br>&gt;&gt; &nbsp; &nbsp; gpfsug-discuss mailing list<br>&gt;&gt; &nbsp; &nbsp; gpfsug-discuss at spectrumscale.org &lt;</font></tt><a href=http://spectrumscale.org/><tt><font size=2>http://spectrumscale.org</font></tt></a><tt><font size=2>&gt;_<br>&gt;&gt;<br>&gt; __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;&gt;<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; _______________________________________________<br>&gt;&gt; &nbsp; &nbsp; gpfsug-discuss mailing list<br>&gt;&gt; &nbsp; &nbsp; gpfsug-discuss at spectrumscale.org &lt;</font></tt><a href=http://spectrumscale.org/><tt><font size=2>http://spectrumscale.org</font></tt></a><tt><font size=2>&gt;<br>&gt;&gt; &nbsp; &nbsp; </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>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; &nbsp; &nbsp; _______________________________________________<br>&gt;&gt; &nbsp; &nbsp; gpfsug-discuss mailing list<br>&gt;&gt; &nbsp; &nbsp; gpfsug-discuss at spectrumscale.org &lt;</font></tt><a href=http://spectrumscale.org/><tt><font size=2>http://spectrumscale.org</font></tt></a><tt><font size=2>&gt;<br>&gt;&gt; &nbsp; &nbsp; </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>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; _______________________________________________<br>&gt;&gt; gpfsug-discuss mailing list<br>&gt;&gt; gpfsug-discuss at spectrumscale.org<br>&gt;&gt; </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>&gt;&gt;<br>&gt; _______________________________________________<br>&gt; gpfsug-discuss mailing list<br>&gt; gpfsug-discuss at spectrumscale.org<br>&gt; </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>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; gpfsug-discuss mailing list<br>&gt; gpfsug-discuss at spectrumscale.org<br>&gt; </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>&gt;<br>_______________________________________________<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></div><BR>