[Sayan] I think we need to do something really quickly to reduce the impact of Bit Rot on I/O performance. Not sure if this is attributed to using SHA256 but if that is the case we need to consider a lighter weight checksum ASAP so that we can reduce the impact on I/O perf. I have concerns that the future in it's current state may not be usable. It's possibly due to unthrottled nature of signer and using a heavy weight *strong* hash. Using a stronger hash is necessary as signatures are per file. A weaker hash could potentially *miss* detecting a corruption in some cases. There's already a bz (#914874) recommending faster versions of SHA256 for Intel CPUs (and other hashes {BLAKE*}). What timelines are we looking at for this? [Venky] Moreover, I had placed some form of throttling in signer which is disabled by default during complication (therefore in RPMs). During my testing, with this option, CPU utilization went down to ~40% with less impact on client I/Os, but at the cost for longer signature computation times.
REVIEW: http://review.gluster.org/11641 (features/bitrot: throttle signer) posted (#5) for review on master by Venky Shankar (vshankar)
change was merged on mainline branch circa July 2015, closing as NEXTRELEASE (i.e. 3.8)