Bug 763890 - (GLUSTER-2158) checksum computation needs to be changed [NEEDINFO]
checksum computation needs to be changed
Status: CLOSED EOL
Product: GlusterFS
Classification: Community
Component: glusterd (Show other bugs)
mainline
All Linux
low Severity low
: ---
: ---
Assigned To: bugs@gluster.org
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-26 21:35 EST by Pranith Kumar K
Modified: 2015-10-22 11:46 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-22 11:46:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
amukherj: needinfo? (asengupt)


Attachments (Terms of Use)

  None (edit)
Description Pranith Kumar K 2010-11-26 21:35:41 EST
checksum computation needs to change to accommodate the changing options in the new versions, so that a peer running old version can be probed.
Comment 1 Jeff Darcy 2012-02-10 16:48:21 EST
Yes, there are multiple problems with this code.

(1) A new info file will be generated when syncing from a peer, possibly ending up with different contents than the just-fetched version (if the generating function adds more lines than before).  This can cause a checksum mismatch relative to the peer you fetched from, which never had a reason to re-generate its copy and corresponding checksum.

(2) Compute_checksum is just a really weak checksum function.  It amounts to a simple XOR with 1-3 bits shifted, which is inappropriate for human-readable-text input.  We should use a standard checksum/hash with better mixing.

(3) Compute_checksum is always called with GF_CHECKSUM_BUF_SIZE=1024 for the size, often using more bytes than were actually read.  The extra bytes will be zero, so they'll have no effect on the output (see previous point).

(4) The use of 0xbabeb00b as a checksum seed might be considered inappropriate.

There was a user in IRC today who was getting checksum mismatches, probably - but not certainly - due to issue 1 above.  If you'd like to brainstorm about what a more robust checksum approach might look like, I'd be glad to help.
Comment 2 Amar Tumballi 2013-02-26 05:30:14 EST
any action on this? taking off KP from this.
Comment 3 Atin Mukherjee 2015-08-07 02:40:20 EDT
I don't think this is an issue any more. Avra to reconfirm and then we can close it.
Comment 4 Kaleb KEITHLEY 2015-10-22 11:46:38 EDT
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.

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