On Wed, Sep 2, 2015 at 2:05 PM, Venky Shankar <yknev.shan...@gmail.com> wrote:
> On Wed, Sep 2, 2015 at 1:59 PM, Emmanuel Dreyfus <m...@netbsd.org> wrote:
>> Hi
>>
>> Yesterday I experienced the problem of a single user bringing down
>> a glusterfs cluster to its knees because of a high amount of rename
>> operations.
>>
>> I understand rename on DHT can be very costly because data really have
>> to be moved from a brick to another one just for a file name change.
>> Is there a workaround for this behavior?
>
> Not really. DHT uses pointer files (so called link-to) to work around
> moving file contents on rename().
>
>>
>> And more generally, do we have a way to ratelimit FOPs per client, so
>> that one client cannot make the cluster unusable for the others?
>
> There is some form of limiting based on priority (w/ client-pids) in
> io-threads. For bit-rot, I had used token bucket
> based throttling[1] during hash calculation. But that resides on the
> client side for bitrot xlator. It may be beneficial
> to have that on the server side.

[1]: 
https://github.com/gluster/glusterfs/blob/master/xlators/features/bit-rot/src/bitd/bit-rot-tbf.c
>
>>
>> --
>> Emmanuel Dreyfus
>> m...@netbsd.org
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Reply via email to