https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-3468 Lustre <p>We are interested in implementing UID/GID based NRS policies to see what we can get. In order to do this, it is essential to add the UID/GID of the processes that trigger the RPCs into to the request bodies. We implement this by filling the UID/GID into the padding of the request body and then get a 'UID/GID Round Robin' policy by changing CRRN policy (the attaced patch). We know it is not a good implementation though it works fine for testing. And we know it is not easy to implement a good one because we need to handle global user ID over entire cluster. Any advice or idea? Thanks!</p> LU-3468

Add UID/GID into RPC request

Improvement Minor Resolved Won't Fix Peter Jones Li Xi ptr Thu, 13 Jun 2013 04:51:34 +0000 Tue, 14 Jan 2014 02:04:26 +0000 Tue, 14 Jan 2014 02:04:26 +0000 0 6 <p>Is JobStats suitable for this purpose？<br/> <a href="https://jira.hpdd.intel.com/browse/LU-694" class="external-link" target="_blank" rel="nofollow noopener">https://jira.hpdd.intel.com/browse/LU-694</a></p> <p>I would suggest a couple of different things:</p> <ul class="alternate" type="square"> <li>the JobStats information would be a very good way of handling this, and it would allow prioritizing RPC processing between different batch jobs as well as between batch and interactive (e.g. with JobID==batch and without==interactive)</li> <li>the OST and MDT RPCs already contain space for the UID/GID in each of the RPCs (struct obdo and struct mdt_body). That makes it a bit more complex to process the RPCs for NRS, but the ORR policy is already looking into the RPC request to determine the OST object ID and offsets. I'm not sure if the uid/gid fields are always filled in for <em>all</em> OST/MDT RPCs, but they could be.</li> <li>alternately, it might be enough to do round-robin over the UID/GID of the objects being accessed? It wouldn't be 100% fair in every case, but would work for the large majority of cases and would avoid the need to change the network protocol just for this.</li> </ul> <p>In the long term, I'd prefer to develop only a small number of policies that are more sophisticated. Having separate policies for each "parameter" means that it will be difficult to get the best overall performance. Separate UID/GID policies will allow load balancing between users, but will not optimize the IO ordering like ORR.</p> <p>It would be better to have a single NRS policy that can do many things at once, like balance between nodes, users, jobs, sort RPCs within objects, both round-robin and constrained with upper and lower limits for bandwidth or IOPS.</p> <p>Hi Andreas,</p> <p>Thank you so much for the advice! It is really helpful!</p> <p>Has there been any further development on this patch? How does it compare to TBF (<a href="https://jira.whamcloud.com/browse/LU-3558" title="NRS TBF policy for QoS purposes" class="issue-link" data-issue-key="LU-3558"><del>LU-3558</del></a>)? Thanks!</p> <p>Hi Jeff,</p> <p>This a earlier ticket than TBF. Now TBF has implemented jobstat support, which I think can cover most use cases of UID/GID based RPC scheduler. It would be good for me if this ticket is closed.</p> <p>Thank you!</p> <p>ok thanks Li Xi!</p> Development Rank 1|hzvt9r: Rank (Obsolete) 8678