[
https://issues.apache.org/jira/browse/HDDS-13823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang resolved HDDS-13823.
------------------------------------
Fix Version/s: 2.2.0
Resolution: Fixed
> 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
> Assignee: Chenchen Lai
> Priority: Minor
> Labels: pull-request-available
> Fix For: 2.2.0
>
>
> 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]
