Bug 1242393 - Performance: Impact of Bitrot on I/O Performance
Summary: Performance: Impact of Bitrot on I/O Performance
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: bitrot
Version: 3.7.0
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
bugs@gluster.org
URL:
Whiteboard:
Depends On:
Blocks: 1242585 1242809
TreeView+ depends on / blocked
 
Reported: 2015-07-13 09:20 UTC by Nagaprasad Sathyanarayana
Modified: 2016-05-10 12:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1242585 1242809 (view as bug list)
Environment:
Last Closed: 2016-05-10 12:49:46 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Nagaprasad Sathyanarayana 2015-07-13 09:20:41 UTC
[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.

Comment 2 Anand Avati 2015-07-14 06:14:52 UTC
REVIEW: http://review.gluster.org/11641 (features/bitrot: throttle signer) posted (#5) for review on master by Venky Shankar (vshankar)

Comment 4 Kaleb KEITHLEY 2016-05-10 12:49:46 UTC
change was merged on mainline branch circa July 2015, closing as NEXTRELEASE (i.e. 3.8)


Note You need to log in before you can comment on or make changes to this bug.