[
https://issues.apache.org/jira/browse/HDDS-13823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18031970#comment-18031970
]
Ivan Andika edited comment on HDDS-13823 at 10/22/25 6:55 AM:
--------------------------------------------------------------
[~rosalai] Thanks for the interest. Assigning this to you.
> This issue is also based on observation, so we need to replicate it first to
> validate the bug is valid.
Note that although the fix should be quite straightforward, we need to
replicate the bug first (this is the hard part). We can try to replicate it in
test by
* Start a brand new OzoneManager that has not initialized s3v volume (i.e.
volumeTable is empty)
* Do some s3v OM operations
*
** OM request validateAndUpdateCache (which will populate the cache) to
generate the OMClientResponse
** Add the OMClientResponse OM double buffer using OzoneManagerDoubleBuffer#add
* Flush the OM double buffer (which will invalidate the cache), can take a
look OzoneManagerDoubleBuffer#flushCurrentBuffer
* Then check the volumeTable TableCache (volumeTable uses FullTableCache)
epochEntries
** The expectation is that the cache related to /s3v should only have 1 entry
(the latest one)
** However, if the bug exists, there might more than one epochEntries
This requires some understanding of OM request and double buffer internals, and
I might miss some steps. Please let me know if there are more questions.
was (Author: JIRAUSER298977):
[~rosalai] Thanks for the interest. Assigning this to you.
> This issue is also based on observation, so we need to replicate it first to
> validate the bug is valid.
Note that although the fix should be quite straightforward, we need to
replicate the bug first (this is the hard part). We can try to replicate it in
test by
* Start a brand new OzoneManager that has not initialized s3v volume (i.e.
volumeTable is empty)
* Do some s3v OM operations
** See OM request validateAndUpdateCache (which will populate the cache) to
generate the OMClientResponse
** Add the OMClientResponse OM double buffer using OzoneManagerDoubleBuffer#add
* Flush the OM double buffer (which will invalidate the cache), can take a
look OzoneManagerDoubleBuffer#flushCurrentBuffer
* Then check the volumeTable TableCache (volumeTable uses FullTableCache)
epochEntries
** The expectation is that the cache related to /s3v should only have 1 entry
(the latest one)
** However, if the bug exists, there might more than one epochEntries
This requires some understanding of OM request and double buffer internals, and
I might miss some steps. Please let me know if there are more questions.
> 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
>
> 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]
