The option is useful in preventing spurious heals from being reported in `volume heal info` output.
-Krutika On Sat, Jul 23, 2016 at 10:05 PM, Lindsay Mathieson < [email protected]> wrote: > 3.7.13 has been running well now for several weeks for me on a rep 3 > sharded volume, VM hosting, but I'm still on op-version 30710, after the > issues with 12 have held off making any changes until confidence was > restored :) > > > Scrolling through the code revealed the following for 3.7.13 > > > *cluster.shd-max-threads* > Default Value: 1 > Description: Maximum number of threads SHD can use per local brick. This > can substantially lower heal times, but can also crush your bricks if you > don't have the storage hardware to support this. > > *cluster.shd-wait-qlength* > Default Value: 1024 > Description: This option can be used to control number of heals that can > wait in SHD per subvolume > > *cluster.locking-scheme* > Default Value: full > Description: If this option is set to granular, self-heal will stop being > compatible with afr-v1, which helps afr be more granular while self-healing > > The first two are I believe, to do with improving heal performance. > However I'm quite happy with the existing defaults and performance, so no > need to tweak them. > > > But I'm not sure as setting cluster.locking-scheme to"granular" will > achieve - I seem to recall that it reduces the locks needs to establish > whats needs to be healed? improves speed of "heal info"? > > > thanks, > > -- > Lindsay Mathieson > > > _______________________________________________ > Gluster-users mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-users >
_______________________________________________ Gluster-users mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-users
