[
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. 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.
was:
In OzoneManager#addS3GVolumeToDB, we see that although the
OmVolumeArgs.updateID of the first initialized s3v volume is -1, 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 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. However, we can
fix it. This issue is also based on observation, so we need to replicate it
first to validate the bug is valid.
> Initial s3v volume cache entry will not be evicted until 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. 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
