[
https://issues.apache.org/jira/browse/HDDS-11721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arpit Agarwal updated HDDS-11721:
---------------------------------
Parent: HDDS-14071 (was: HDDS-8387)
> Container export may fail for Schema v2 container while it is being scanned
> ---------------------------------------------------------------------------
>
> Key: HDDS-11721
> URL: https://issues.apache.org/jira/browse/HDDS-11721
> Project: Apache Ozone
> Issue Type: Sub-task
> Components: Ozone Datanode
> Reporter: Ethan Rose
> Assignee: Rishabh Patel
> Priority: Major
> Labels: pull-request-available
>
> For container schema versions older than v3, there is a DB handle cache that
> uses reference counting to handle cache eviction. The container scanner is
> holding a reference to the DB as it is scanning the blocks while the
> container is being exported. The scanner operates without a lock which is
> expected since it is a slow, read-only background process. However, the
> export code makes an assumption that every caller who has allocated a schema
> v2 DB reference has done so under a container lock, and it will block until
> the other thread has released the lock, meaning that once it tries to free
> the DB, it knows there are no other references. In this case the scanner has
> a reference but no lock, so export obtains the write lock and attempts to
> evict the DB from the cache, but it fails due to the scanner's reference.
> This is incorrect because export should be a read-only operation. It is a
> copy, not a move, so it should not be evicting from the cache. We should
> remove the cache eviction step, and probably convert the write lock it takes
> to at least a read lock.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
