[
https://issues.apache.org/jira/browse/HDDS-13823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Andika updated HDDS-13823:
-------------------------------
Description:
In OzoneManager#addS3GVolumeToDB, we see that although the
OmVolumeArgs.updateID of the first initialized s3v volume is -1
(DEFAULT_OM_UPDATE_ID), the cache epoch still uses the max transaction ID. This
implies that the initial s3v volume cache entry will never be evicted (since it
has the highest epoch) unless the OM is restarted and the s3v volume cache are
recreated.
This is a minor issue since we only retain one OmVolumeArgs and this cache
entry will not exist in subsequent OM restart since s3v volume is already
created. This issue is also based on observation, so we need to replicate it
first to validate the bug is valid.
We can fix it by setting the first ever volume cache entry epoch to -1
(DEFAULT_OM_UPDATE_ID) instead.
was:
In OzoneManager#addS3GVolumeToDB, we see that although the
OmVolumeArgs.updateID of the first initialized s3v volume is -1
(DEFAULT_OM_UPDATE_ID), the cache epoch still uses the max transaction ID. This
implies that the initial s3v volume cache entry will never be evicted (since it
has the highest epoch) unless the OM is restarted and the s3v volume cache are
recreated.
This is a minor issue since we only retain one OmVolumeArgs and this cache
entry will not exist in subsequent OM restart since s3v volume is already
created. This issue is also based on observation, so we need to replicate it
first to validate the bug is valid.
We can fix it by setting the epoch to -1 (DEFAULT_OM_UPDATE_ID) instead.
> Initial s3v volume cache entry will not be evicted until OM restart
> -------------------------------------------------------------------
>
> Key: HDDS-13823
> URL: https://issues.apache.org/jira/browse/HDDS-13823
> Project: Apache Ozone
> Issue Type: Bug
> Reporter: Ivan Andika
> Priority: Minor
>
> In OzoneManager#addS3GVolumeToDB, we see that although the
> OmVolumeArgs.updateID of the first initialized s3v volume is -1
> (DEFAULT_OM_UPDATE_ID), the cache epoch still uses the max transaction ID.
> This implies that the initial s3v volume cache entry will never be evicted
> (since it has the highest epoch) unless the OM is restarted and the s3v
> volume cache are recreated.
> This is a minor issue since we only retain one OmVolumeArgs and this cache
> entry will not exist in subsequent OM restart since s3v volume is already
> created. This issue is also based on observation, so we need to replicate it
> first to validate the bug is valid.
> We can fix it by setting the first ever volume cache entry epoch to -1
> (DEFAULT_OM_UPDATE_ID) instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
