[
https://issues.apache.org/jira/browse/CASSANDRA-20190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938570#comment-17938570
]
Michael Semb Wever edited comment on CASSANDRA-20190 at 3/26/25 11:54 AM:
--------------------------------------------------------------------------
{quote}If that reading is correct, we should also port this over. And if
possible add some way to recognize broken order in the summary and reject &
recreate it.
{quote}
Yes. We want to fix 5.0, and detecting these broken index summary files and
simply ignoring them and letting them be recreated makes sense. (This needs to
be in trunk too, as users can ofc upgrade from <=5.0.3 to 5.1.)
Maybe adding data in test/data/legacy-sstables/ and test/assertion in
LegacySSTable to validate the recreation process works… ?
was (Author: michaelsembwever):
{quote}If that reading is correct, we should also port this over. And if
possible add some way to recognize broken order in the summary and reject &
recreate it.
{quote}
Yes. We want to fix 5.0, and detecting these broken index summary files and
simply ignoring them and letting them be recreated makes sense.
> MemoryUtil.setInt/getInt and similar use the wrong endianness
> -------------------------------------------------------------
>
> Key: CASSANDRA-20190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20190
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Local/Other
> Reporter: Branimir Lambov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> `NativeCell`, `NativeClustering` and `NativeDecoratedKey` use the above
> methods from `MemoryUtil` to write and read data from native memory. As far
> as I can see they are meant to write data in big endian. They do not (they
> always correct to little endian).
> Moreover, they disagree with their `ByByte` versions on big-endian machines
> (which is only likely an issue on aligned-access architectures (x86 and arm
> should be fine)).
> The same is true for the methods in `Memory`, used by compression metadata as
> well as index summaries.
> We need to verify that this does not cause any problems, and to change the
> methods to behave as expected and document the behaviour by explicitly using
> `ByteOrder.LITTLE_ENDIAN` for any data that may have been persisted on disk
> with the wrong endianness.
>
> The current MemoryUtil behaviour (before the fix):
> ||Native
> order||MemoryUtil.setX||MemoryUtil.setXByByte||MemoryUtil.getX||MemoryUtil.getXByByte||
> |BE|LE|BE|LE|BE|
> |LE|LE|LE|LE|LE|
> shortly: MemoryUtil.setX/getX is LE, MemoryUtil.setXByByte/getXByByte is
> Native
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
