Bug 1242393
| Summary: | Performance: Impact of Bitrot on I/O Performance | |||
|---|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Nagaprasad Sathyanarayana <nsathyan> | |
| Component: | bitrot | Assignee: | bugs <bugs> | |
| Status: | CLOSED NEXTRELEASE | QA Contact: | ||
| Severity: | high | Docs Contact: | bugs <bugs> | |
| Priority: | urgent | |||
| Version: | 3.7.0 | CC: | bugs, ravishankar, smohan, vshankar | |
| Target Milestone: | --- | Keywords: | Triaged | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1242585 1242809 (view as bug list) | Environment: | ||
| Last Closed: | 2016-05-10 12:49:46 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1242585, 1242809 | |||
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) |
[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.