[Gluster-devel] Throttling xlator on the bricks

[Shreyas Siravara]

Just out of curiosity, what benefits do we think this throttling xlator would provide over the "enable-least-priority" option (where we put all the fops from SHD, etc into a least pri queue)?

 
> On Jan 25, 2016, at 12:29 AM, Venky Shankar <vshankar at redhat.com> wrote:
> 
> On Mon, Jan 25, 2016 at 01:08:38PM +0530, Ravishankar N wrote:
>> On 01/25/2016 12:56 PM, Venky Shankar wrote:
>>> Also, it would be beneficial to have the core TBF implementation as part of
>>> libglusterfs so as to be consumable by the server side xlator component to
>>> throttle dispatched FOPs and for daemons to throttle anything that's outside
>>> "brick" boundary (such as cpu, etc..).
>> That makes sense. We were initially thinking to overload posix_rchecksum()
>> to do the SHA256 sums for the signer.
> 
> That does have advantages by avoiding network rountrips by computing SHA* locally.
> TBF could still implement ->rchecksum and throttle that (on behalf of clients,
> residing on the server - internal daemons). Placing the core implementation as
> part of libglusterfs would still provide the flexibility.
> 
>> 
>> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gluster.org_mailman_listinfo_gluster-2Ddevel&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=N7LE2BKIHDDBvkYkakYthA&m=9W9xtRg0TIEUvFL-8HpUCux8psoWKkUbEFiwqykRwH4&s=OVF0dZRXt8GFcIxsHlkbNjH-bjD9097q5hjVVHgOFkQ&e=