On Wed, Sep 2, 2015 at 2:05 PM, Venky Shankar <yknev.shankar@xxxxxxxxx> wrote: > On Wed, Sep 2, 2015 at 1:59 PM, Emmanuel Dreyfus <manu@xxxxxxxxxx> 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 >> manu@xxxxxxxxxx >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@xxxxxxxxxxx >> http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
