[
https://issues.apache.org/jira/browse/HDDS-10590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hemant Kumar updated HDDS-10590:
--------------------------------
Description:
SstFilteringService marks the sstFilter flag for a snapshot and updates the
RocksDB,
[code|https://github.com/apache/ozone/blob/2f2234c7b61714404399ada8f31b3fb4772b613a/hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/SstFilteringService.java#L123].
It may cause snapshot chain corruption (probably not after the fix:
https://github.com/apache/ozone/pull/6443) or data inconsistency due to race
condition because SstFilteringService updates snapshot info in parallel to
SnapshotPurge and SnapshotProperty which also update snapshot info. Even tho
SstFilteringService takes a lock before updating snapshotInfo, SnapshotPurge
and SnapshotProperty APIs don't take a lock and rely on OMStateMachine because
OMStateMachine is going to process each request sequentially.
In general, each update to snapshotInfoTable should go through API but that is
not possible for *SstFilteringService* because *SstFilteringService* runs on
each OM independently. Hence it is directly updating snapshotInfoTable.
So we need to introduce the lock for SnapshotPurge and SetSnapshotProperty APIs
unless there is another better way.
was:
SstFilteringService marks the sstFilter flag for a snapshot and updates the
RocksDB,
[code|https://github.com/apache/ozone/blob/2f2234c7b61714404399ada8f31b3fb4772b613a/hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/SstFilteringService.java#L123].
It may cause snapshot chain corruption (probably not after the fix:
https://github.com/apache/ozone/pull/6443) or data inconsistency due to race
condition because SstFilteringService updates snapshot info in parallel to
SnapshotPurge and SnapshotProperty which also update snapshot info. Even tho
SstFilteringService takes a lock before updating snapshotInfo, SnapshotPurge
and SnapshotProperty APIs don't take a lock and rely on OMStateMachince because
OMStateMachince is going to process each request sequentially.
In general, each update to snapshotInfoTable should go through API but that is
not possible for *SstFilteringService* because *SstFilteringService* runs on
each OM independently. Hence it is directly updating snapshotInfoTable.
So we need to introduce the lock for SnapshotPurge and SetSnapshotProperty APIs
unless there is another better way.
> SstFilteringService updating snapshotInfo directly
> --------------------------------------------------
>
> Key: HDDS-10590
> URL: https://issues.apache.org/jira/browse/HDDS-10590
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Hemant Kumar
> Priority: Major
>
> SstFilteringService marks the sstFilter flag for a snapshot and updates the
> RocksDB,
> [code|https://github.com/apache/ozone/blob/2f2234c7b61714404399ada8f31b3fb4772b613a/hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/SstFilteringService.java#L123].
> It may cause snapshot chain corruption (probably not after the fix:
> https://github.com/apache/ozone/pull/6443) or data inconsistency due to race
> condition because SstFilteringService updates snapshot info in parallel to
> SnapshotPurge and SnapshotProperty which also update snapshot info. Even tho
> SstFilteringService takes a lock before updating snapshotInfo, SnapshotPurge
> and SnapshotProperty APIs don't take a lock and rely on OMStateMachine
> because OMStateMachine is going to process each request sequentially.
> In general, each update to snapshotInfoTable should go through API but that
> is not possible for *SstFilteringService* because *SstFilteringService* runs
> on each OM independently. Hence it is directly updating snapshotInfoTable.
> So we need to introduce the lock for SnapshotPurge and SetSnapshotProperty
> APIs unless there is another better way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
