<font size=2 face="sans-serif">Hi - sorry for delayed response..
as Alex started.. let me add a little though on that</font><br><br><br><font size=2 face="sans-serif">your said ... </font><br><font size=2 face="sans-serif">you came from GL4 ... to now GL6
... MES update is only supported , when converting everything to mmvdisk
... so I suspect.. you did it already</font><br><br><font size=2 face="sans-serif">next.. </font><br><font size=2 face="sans-serif">by going through this MES upgrade ...
all GNR tracks are re-balanced.. among all (old+new) drives.. (this
comment is for those, who not so familiar with MES update) </font><br><br><font size=2 face="sans-serif">then .. </font><br><font size=2 face="sans-serif">from a performance perspective it makes
no(reasonable/able to measure) difference , if you have vdisks with
different sizes. .. the GNR layer will carry about your IOs to your
NSDs and by underlaying vdisk layer, GNR code will direct them
to the final physical disks . By the fact, the vdisks are served from the
same IOnodes anyway - so same communication channels from client to NSD
server .... --> we can say.. you can relax, that this given
NSD size of 330T or 380T .. won't make any difference... </font><br><br><font size=2 face="sans-serif">..but.. to add some flavor here ;-)
</font><br><font size=2 face="sans-serif"> in case you use/have different
failure groups in your configuration .. .. as said.. if ..
.then - . different NSD sizes makes a difference .. because the algorithm
to allocate space .. does this currently in a round robin fashion over
all NSDs .. At least, thats the default and I'm not aware , that you can
change it nor customize it yet... IN a round robin allocation, each disk
is given equal allocation priority - you can double check this by
mmlsfs <fs> -s </font><br><br><font size=2 face="sans-serif">So by default there 's no heuristic
to take different NSD sizes into account for allocation new blocks - as
being said.. this is ONLY affecting you, if you have multiple Failure Groups
.. </font><br><font size=2 face="sans-serif">and from your email .. I conclude..
that 's not the case .. </font><br><br><br><font size=2 face="sans-serif">after all .. </font><br><font size=2 face="sans-serif">I'm sure every administrator these days
has multiple things (=too much) to do .. .. so I would'nt go the
extra mile to recreate NSD (=vdisk) just to have them all the same size
.. as long you have a strong reason to do so .. ;-) .. </font><br><font size=2 face="sans-serif">just my view on it.. </font><br><br><font size=2 face="sans-serif">cheers</font><br><font size=2 face="sans-serif">laff</font><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Alexander Wolf"
<A.Wolf-Reber@de.ibm.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">gpfsug-discuss@spectrumscale.org</font><br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">gpfsug-discuss@spectrumscale.org</font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">10/25/2019 07:14 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[EXTERNAL] Re:
[gpfsug-discuss] ESS - Considerations when adding NSD space?</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><font size=2 face="Arial">Bob,</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">from what you describe I would assume that
you have now "old" vdisks that span four enclosures and "new"
vdisks that span the two new enclosures. So you already are unbalanced
at the vdisk level. From a performance point I would guess the optimum
would be to have the new NSDs being half the size of the old ones. But
honestly I do not know how much of a difference it really makes.</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">Fred is right, if you can you shoud always
go for a homogenous setup. On the other hand if you can't, you can't.</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">Mit freundlichen Grüßen / Kind regards</font><font size=2 face="sans-serif"></font><p><img src=cid:_4_DD1B31D0DD1B2DB40062D983C125849E style="border:0px solid;"><p><table width=697 style="border-collapse:collapse;"><tr height=8><td width=202 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><img src=cid:_4_DD1B4110DD1B3D240062D983C125849E alt="IBM Spectrum Scale" style="border:0px solid;"><br><font size=2 face="sans-serif"> </font><td width=31 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=3 face="sans-serif">
</font><td width=464 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=3 face="Arial"><b>Dr.
Alexander Wolf-Reber</b></font><font size=1 face="Arial"><br>Spectrum Scale Release Lead Architect<br>Department M069 / Spectrum Scale Software Development<br><br>+49-160-90540880<br>a.wolf-reber@de.ibm.com</font></table><br><img src=cid:_4_DD2749A4DD1B36B00062D983C125849E style="border:0px solid;"><p><font size=1 color=#a2a2a2 face="Arial">IBM Deutschland Research &
Development GmbH / Vorsitzende des Aufsichtsrats: Matthias Hartmann / Geschäftsführung:
Dirk Wittkopp<br>Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294</font><p><font size=2 face="Arial"> </font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">----- Original message -----<br>From: "Frederick Stock" <stockf@us.ibm.com><br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: gpfsug-discuss@spectrumscale.org<br>Cc: gpfsug-discuss@spectrumscale.org<br>Subject: [EXTERNAL] Re: [gpfsug-discuss] ESS - Considerations when adding
NSD space?<br>Date: Thu, Oct 24, 2019 17:55<br> </font><br><font size=3 face="Arial">Bob as I understand having different size
NSDs is still not considered ideal even for ESS. I had another customer
recently add storage to an ESS system and they were advised to first check
the size of their current vdisks and size the new vdisks to be the same.
</font><br><font size=2 face="sans-serif"><br>Fred<br>__________________________________________________<br>Fred Stock | IBM Pittsburgh Lab | 720-430-8821<br>stockf@us.ibm.com</font><br><font size=3 face="Arial"> </font><br><font size=3 face="Arial"> </font><br><font size=3 face="Arial">----- Original message -----<br>From: "Oesterlin, Robert" <Robert.Oesterlin@nuance.com><br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>Cc:<br>Subject: [EXTERNAL] [gpfsug-discuss] ESS - Considerations when adding NSD
space?<br>Date: Thu, Oct 24, 2019 11:34 AM<br> </font><br><font size=2 face="Arial">We recently upgraded our GL4 to a GL6 (trouble
free process for those considering FYI). I now have 615T free (raw) in
each of my recovery groups. I’d like to increase the size of one
of the file systems (currently at 660T, I’d like to add 100T).</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">My first thought was going to be:</font><br><font size=2 face="Arial"> </font><br><font size=3 face="Arial">mmvdisk vdiskset define --vdisk-set fsdata1
--recovery-group rg_gssio1-hs,rg_gssio2-hs --set-size 50T --code 8+2p --block-size
4m --nsd-usage dataOnly --storage-pool data</font><br><font size=3 face="Arial">mmvdisk vdiskset create --vdisk-set fs1data1
</font><br><font size=2 face="Arial">mmvdisk filesystem add --filesystem fs1 </font><font size=3 face="Arial">--vdisk-set
fs1data1 </font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">I know in the past use of mixed size NSDs
was frowned upon, not sure on the ESS. </font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">The other approach would be add two larger
NSDs (current ones are 330T) of 380T, migrate the data to the new ones
using mmrestripe, then delete the old ones. The other benefit of this process
would be to have the file system data better balanced across all the storage
enclosures.</font><br><font size=2 face="Arial"> </font><br><font size=2 face="Arial">Any considerations before I do this? Thoughts?</font><br><font size=2 face="Arial"> </font><br><font size=3 face="Arial">Bob Oesterlin</font><br><font size=3 face="Arial">Sr Principal Storage Engineer, Nuance</font><br><font size=3 face="Arial"> </font><p><tt><font size=2>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org</font></tt><tt><font size=2 color=blue><u><br></u></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank"><tt><font size=2 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=2></font></tt><br><font size=3 face="Arial"> </font><br><font size=2 face="Arial"> </font><br><tt><font size=2>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org</font></tt><tt><font size=2 color=blue><u><br></u></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank"><tt><font size=2 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=2></font></tt><br><font size=2 face="Arial"> </font><br><tt><font size=2>_______________________________________________<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><BR>