<font size=2 face="sans-serif">Thanks for that reference. Further
research indicates that GRIO on XFS required Irix/SGI hardware features
and GRIO is not in any recent implementations of XFS.</font><br><font size=2 face="sans-serif"><br>Functionally GRIO, when it worked was kind of a logical complement or opposite
of GPFS/QOS. GRIO was to be used to reserve bandwidth for critical
applications; whereas GPFS 4.2/QOS primary purpose to restrict the
IO bandwidth consumed by not-performance critical applications.
Of course if you restrict set X to use no more than B, than you have
effectively reserved TotalAvailable-B for the set ~X. It may interest
you to know that the primary GPFS/QOS enforcement mechanisms are based
on an implementation of Token Bucket ( </font><a href=https://en.wikipedia.org/wiki/Token_bucket><font size=2 color=blue face="sans-serif">wikipedia.org/wiki/Token_bucket</font></a><font size=2 face="sans-serif"></font><font size=1 face="sans-serif">,</font><font size=1 face=" Arial"></font><font size=2 color=#2f2f2f face=" Arial">US Patent 9178827 )</font><br><br><font size=2 face="sans-serif">--marc </font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Jan-Frode Myklebust
<janfrode@tanso.net></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">gpfsug main discussion
list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">06/15/2016 01:55 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
QoS question</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=3>XFS on Irix had a feature similar to QoS, called GRIO
(guaranteed rate I/O), where applications could reserve a given bandwidth.<br></font><font size=3 color=blue><u><br></u></font><a href="http://www.sgistuff.net/software/irixintro/documents/xfs-whitepaper.html"><font size=3 color=blue><u>http://www.sgistuff.net/software/irixintro/documents/xfs-whitepaper.html</u></font></a><font size=3><br><br>Sounds somewhat similar to QoS, but focused on giving applications guaranteed
bandwidth, not iops.<br><br><br><br>-jf<br></font><br><br><font size=3>ons. 15. jun. 2016 kl. 00.08 skrev Marc A Kaplan <</font><a href=mailto:makaplan@us.ibm.com><font size=3 color=blue><u>makaplan@us.ibm.com</u></font></a><font size=3>>:</font><br><font size=2 face="sans-serif">Yes, in QOS for 4.2.0 there are some
simple assumptions that may not make a lot of sense in some configurations,
especially configurations with many (100s) of nodes mounting the same file
system... You can try out what you suggested and in 4.2.0
I think it will pretty much work as you suggest -- essentially you are
allocating 466 maintenance iops to every node, knowing that most of those
nodes will not be using their allocation of IOPS.</font><font size=3><br></font><font size=2 face="sans-serif"><br>In later releases, you may find that we will address some of these kinds
of quirks in QOS.</font><font size=3><br></font><font size=2 face="sans-serif"><br>QOS is a new feature for GPFS, and I don't think you'll find anything like
it in any commercial file system offering. (Correct me with example(s)
if I am wrong on this point.)<br>So think of it as "release 1.0" (of QOS) and let us know how
well it works for you and how it might be improved....</font><font size=3><br></font><font size=2 face="sans-serif"><br>--marc of Spectrum(GP)FS</font><font size=3><br><br><br></font><font size=1 color=#5f5f5f face="sans-serif"><br>From: </font><font size=1 face="sans-serif">"Buterbaugh,
Kevin L" <Kevin.Buterbaugh@Vanderbilt.Edu></font><font size=1 color=#5f5f5f face="sans-serif"><br>To: </font><font size=1 face="sans-serif">gpfsug
main discussion list <</font><a href="mailto:gpfsug-discuss@spectrumscale.org" target=_blank><font size=1 color=blue face="sans-serif"><u>gpfsug-discuss@spectrumscale.org</u></font></a><font size=1 face="sans-serif">></font><font size=1 color=#5f5f5f face="sans-serif"><br>Date: </font><font size=1 face="sans-serif">06/14/2016
04:50 PM</font><font size=1 color=#5f5f5f face="sans-serif"><br>Subject: </font><font size=1 face="sans-serif">[gpfsug-discuss]
QoS question</font><font size=1 color=#5f5f5f face="sans-serif"><br>Sent by: </font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target=_blank><font size=1 color=blue face="sans-serif"><u>gpfsug-discuss-bounces@spectrumscale.org</u></font></a><font size=3><br></font><hr noshade><font size=3><br><br><br>Hi All, <br><br>We have recently upgraded to GPFS 4.2.0-3 and so I am getting ready to
dive into my first attempts at using the new QoS features. I want
to make sure I am understanding the documentation:</font><br><font size=2>"The IOPS values that you set in an mmchqos command
apply to all I/O operations that are issued by all the nodes that have
the specified file system mounted. You should adjust your allocations of
IOPS accordingly. </font><p><font size=2>For example, if you 600 IOPS to the maintenance class,
and there are six nodes that have the file system mounted, then QoS allocates
100 IOPS to the maintenance class of each node. If you then run maintenance
commands that affect only three of the nodes, the commands runs with an
actual allocation of 300 IOPS, or 100 IOPS per node. To run maintenance
commands that affect three nodes with an actual allotment of 600 IOPS,
or 200 per node, allocate 1200 IOPS to the maintenanceclass. "</font><p><font size=3>We have a ~700 node cluster with 15 NSD servers.
Here’s how I interpret the above assuming that I have determined that
I want to allow 7,000 IOPs … please correct me if I’m wrong...<br><br>7,000 IOPs / 700 nodes would be 10 IOPs per node.<br><br>But I want those 7,000 IOPs to be divided amongst my 15 NSD servers that
are going to be doing the maintenance (a restripe, for example), so 7,000
/ 15 = 466.67.<br><br>466.67 * 700 (nodes in cluster) = 326,666.67. So I would allocate
326,666 IOPs to the maintenance class?<br><br>Thanks in advance…<br><br>Kevin<br>—<br>Kevin Buterbaugh - Senior System Administrator<br>Vanderbilt University - Advanced Computing Center for Research and Education</font><p><a href=mailto:Kevin.Buterbaugh@vanderbilt.edu target=_blank><font size=3 color=blue><u>Kevin.Buterbaugh@vanderbilt.edu</u></font></a><font size=3>-
(615)875-9633</font><p><font size=3><br><br></font><tt><font size=2><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at </font></tt><a href=http://spectrumscale.org/ target=_blank><tt><font size=2 color=blue><u>spectrumscale.org</u></font></tt></a><font size=3 color=blue><u><br></u></font><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><font size=3><br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at </font><a href=http://spectrumscale.org/ target=_blank><font size=3 color=blue><u>spectrumscale.org</u></font></a><font size=3 color=blue><u><br></u></font><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target=_blank><font size=3 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></a><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><p><BR>