[
https://issues.apache.org/jira/browse/HDDS-8214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devesh Kumar Singh updated HDDS-8214:
-------------------------------------
Description:
h5. {*}Container Level Info (Tab1){*}: A new tab as shown below will present
the container level info showing mismatch between SCM and OM. Some containers
are deleted in SCM but seem to be referred to by files/keys in OM, So recon
needs to detect if any container is missing or not from OM perspective. This
requirement came up due to missing containers in the BoFA “Preferred Networks”
cluster where OM still maintains those deleted containers along with key
mapping and those keys cannot be reached as containers doesn’t exists at SCM,
which is a data loss situation.Issue details are at
https://issues.apache.org/jira/browse/HDDS-7701.
h5. Key Level Info (Tab 2): A new tab as shown above will be used to represent
below information.
* Number of open keys.
* Amount of data mapped to open keys.
* Number of pending delete keys.
* Amount of data mapped to pending delete keys
* Keys that are mapped to containers in *DELETED* state in *SCM*
* Should never happen, but we want to show this in case if any.
was:
h5. {*}Container Level Info (Tab1){*}: A new tab as shown below will present
the container level info showing mismatch between SCM and OM. Some containers
are deleted in SCM but seem to be referred to by files/keys in OM, So recon
needs to detect if any container is missing or not from OM perspective. This
requirement came up due to missing containers in the BoFA “Preferred Networks”
cluster where OM still maintains those deleted containers along with key
mapping and those keys cannot be reached as containers doesn’t exists at SCM,
which is a data loss situation.Issue details are at
https://issues.apache.org/jira/browse/HDDS-7701.
Here in this tab, below list of containers will be shown along with their key
mappings:
* Container is present in OM, but not in SCM.
* Container is present in SCM, but not in OM.
If a container is present in both OM and SCM, then it is of no relevance and
will not be shown here.
UI representation can be a tabular format with “Container Id”,
“ContainerState”, “Keys”, “Exists At”
h5. Key Level Info (Tab 2): A new tab as shown above will be used to represent
below information.
* Number of open keys.
* Amount of data mapped to open keys.
* Number of pending delete keys.
* Amount of data mapped to pending delete keys
* Keys that are mapped to containers in *DELETED* state in *SCM*
* Should never happen, but we want to show this in case if any.
> Recon - OM DB Insights
> ----------------------
>
> Key: HDDS-8214
> URL: https://issues.apache.org/jira/browse/HDDS-8214
> Project: Apache Ozone
> Issue Type: Improvement
> Components: Ozone Recon
> Reporter: Devesh Kumar Singh
> Assignee: Devesh Kumar Singh
> Priority: Major
> Labels: pull-request-available
>
> h5. {*}Container Level Info (Tab1){*}: A new tab as shown below will present
> the container level info showing mismatch between SCM and OM. Some containers
> are deleted in SCM but seem to be referred to by files/keys in OM, So recon
> needs to detect if any container is missing or not from OM perspective. This
> requirement came up due to missing containers in the BoFA “Preferred
> Networks” cluster where OM still maintains those deleted containers along
> with key mapping and those keys cannot be reached as containers doesn’t
> exists at SCM, which is a data loss situation.Issue details are at
> https://issues.apache.org/jira/browse/HDDS-7701.
> h5. Key Level Info (Tab 2): A new tab as shown above will be used to
> represent below information.
> * Number of open keys.
> * Amount of data mapped to open keys.
> * Number of pending delete keys.
> * Amount of data mapped to pending delete keys
> * Keys that are mapped to containers in *DELETED* state in *SCM*
> * Should never happen, but we want to show this in case if any.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
