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.
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 ( wikipedia.org/wiki/Token_bucket , US Patent 9178827 ) --marc From: Jan-Frode Myklebust <[email protected]> To: gpfsug main discussion list <[email protected]> Date: 06/15/2016 01:55 AM Subject: Re: [gpfsug-discuss] QoS question Sent by: [email protected] XFS on Irix had a feature similar to QoS, called GRIO (guaranteed rate I/O), where applications could reserve a given bandwidth. http://www.sgistuff.net/software/irixintro/documents/xfs-whitepaper.html Sounds somewhat similar to QoS, but focused on giving applications guaranteed bandwidth, not iops. -jf ons. 15. jun. 2016 kl. 00.08 skrev Marc A Kaplan <[email protected]>: 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. In later releases, you may find that we will address some of these kinds of quirks in QOS. 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.) 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.... --marc of Spectrum(GP)FS From: "Buterbaugh, Kevin L" <[email protected]> To: gpfsug main discussion list <[email protected]> Date: 06/14/2016 04:50 PM Subject: [gpfsug-discuss] QoS question Sent by: [email protected] Hi All, 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: "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. 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. " 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... 7,000 IOPs / 700 nodes would be 10 IOPs per node. 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. 466.67 * 700 (nodes in cluster) = 326,666.67. So I would allocate 326,666 IOPs to the maintenance class? Thanks in advance… Kevin — Kevin Buterbaugh - Senior System Administrator Vanderbilt University - Advanced Computing Center for Research and Education [email protected] (615)875-9633 _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
