[
https://issues.apache.org/jira/browse/HDDS-11222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Andika updated HDDS-11222:
-------------------------------
Description:
KeyValueContainerData#getBlockKey passes the localID using Long#toString, which
does not generate a fixed-byte array. This means that the RocksDB table will
sort the block key "lexicographically" instead of "numerically". For example,
numerically localID 9 < 100, but lexicographically "9" > "100". This means that
things like startLocalID in BlockManagerImpl#listBlock need to assume that the
localIDs returned are the ones with lexicographically larger.
We can fix it by using fixed byte array to represent the Long value (how it's
done in LongCodec). However, we cannot simply change it without breaking a lot
of existing codes. So probably, we need to live with this.
was:
KeyValueContainerData#getBlockKey passes the localID using Long#toString, which
does not generate a fixed-byte array. This means that the RocksDB table will
sort the block key "lexicographically" instead of "numerically". For example,
numerically localID 9 < 100, but lexicographically "9" < "100". This means that
things like startLocalID in BlockManagerImpl#listBlock need to assume that the
localIDs returned are the ones with lexicographically larger.
We can fix it by using fixed byte array to represent the Long value (how it's
done in LongCodec). However, we cannot simply change it without breaking a lot
of existing codes. So probably, we need to live with this.
> LocalID in DN BlockKey should be persisted as fixed byte array
> --------------------------------------------------------------
>
> Key: HDDS-11222
> URL: https://issues.apache.org/jira/browse/HDDS-11222
> Project: Apache Ozone
> Issue Type: Improvement
> Components: Ozone Datanode
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
>
> KeyValueContainerData#getBlockKey passes the localID using Long#toString,
> which does not generate a fixed-byte array. This means that the RocksDB table
> will sort the block key "lexicographically" instead of "numerically". For
> example, numerically localID 9 < 100, but lexicographically "9" > "100". This
> means that things like startLocalID in BlockManagerImpl#listBlock need to
> assume that the localIDs returned are the ones with lexicographically larger.
> We can fix it by using fixed byte array to represent the Long value (how it's
> done in LongCodec). However, we cannot simply change it without breaking a
> lot of existing codes. So probably, we need to live with this.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
