| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently the author of our old crc32 assumed that shifting an int
to the right sign-extends, which is not always the case. Result is,
building and running make test on s390x fails. The fix is to force
a sign-extension using the "xor 0x80; sub 0x80" trick.
N.B. This does not cause a compatibility problem, because by a
miracle the "broken" crc32_alt was actually computing a stock
crc32, same that zlib has. Therefore, if someone, somewhere,
ran a Swift cluster on s390x with erasure coding policy,
the data in it is already stored with zlib checksums, as we
do it now anyway. This fix only permits the tests pass, which
used the bad data sample from x86.
Change-Id: Ibd5e4e6c02be00540a9648cc7e0f8efda275bf3f
Related-Change: Ib5ea2a830c7c23d66bf2ca404a3eb84ad00c5bc5
Related-Bug: 1666320
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we had our own CRC that was almost but not quite like
zlib's implementation. However,
* it hasn't been subjected to the same rigor with regard to error-detection
properties and
* it may not even get used, depending upon whether zlib happens to get
loaded before or after liberasurecode.
Now, we'll use zlib's CRC-32 when writing new frags, while still
tolerating frags that were created with the old implementation.
Change-Id: Ib5ea2a830c7c23d66bf2ca404a3eb84ad00c5bc5
Closes-Bug: 1666320
|
| |
|
|
|
|
|
|
|
| |
It isn't the CRC we want, and we never used it anyway. While we may
define INTEL_SSE41 or INTEL_SSE42 if CPU seems to support it, we've
never defined INTEL_SSE4.
Change-Id: I04e1dd6458ccde58a0a2f3f4d6947569a31e9697
Partial-Bug: 1666320
|
| |
|
|
|
|
|
|
|
|
| |
If the underlying jerasure implementation is old (pre-jerasure.org),
then it will not contain an uninit function for the underlying GF
object. Since this is only used in alg_sig, which is not used by
anything else at the moment, we stub it out if it does not exist.
Once we make the change to have alg_sig use the internal GF functions,
this whole problem goes away.
|
| |
|
|
| |
https://bitbucket.org/tsg-/liberasurecode/issue/12/make-valgrind-test-fails
|
| | |
|
| |
|
|
| |
existing warnings.
|
| |
|
|
|
|
| |
.. also check for errors
Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>
|
| |
|
|
| |
from jerasure
|
| | |
|
| |
|
|
|
|
| |
... shared library should not call exit()
Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>
|
| |
|
|
| |
Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>
|
| | |
|
| |
|
|
|
|
|
|
| |
NOTE: We need to ensure that any erasure code backend using algebraic
signatures *must use* the same exact GF as those used in this library. This
usually means same 'w' and primitive polynomial.
I plan to make the same change to Jerasure, so it will be compatible.
|
| |
|
|
| |
Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>
|
| |
|
|
| |
Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>
|
| |
|
|
| |
Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>
|
| |
|
|
| |
Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>
|
|
|
Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>
|