Bug 763890 (GLUSTER-2158)
| Summary: | checksum computation needs to be changed | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Pranith Kumar K <pkarampu> |
| Component: | glusterd | Assignee: | bugs <bugs> |
| Status: | CLOSED EOL | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | mainline | CC: | amukherj, asengupt, bugs, chrisw, gluster-bugs, jdarcy, rwheeler |
| Target Milestone: | --- | Keywords: | FutureFeature, Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-10-22 15:46:38 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Pranith Kumar K
2010-11-27 02:35:41 UTC
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. any action on this? taking off KP from this. I don't think this is an issue any more. Avra to reconfirm and then we can close it. 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. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |