[jira] [Resolved] (HDDS-13823) Initial s3v volume cache entry will not be evicted until OM restart

["Wei-Chiu Chuang (Jira)" <ji...@apache.org>]

     [ 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: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org