Devesh Kumar Singh created HDDS-15037:
-----------------------------------------
Summary: Include original IOException in delete-flow error path
before volume-scan rethrow
Key: HDDS-15037
URL: https://issues.apache.org/jira/browse/HDDS-15037
Project: Apache Ozone
Issue Type: Task
Components: Ozone Datanode
Affects Versions: 2.1.0
Reporter: Devesh Kumar Singh
Assignee: Devesh Kumar Singh
*Description:*
When container deletion fails in the DN after markContainerForDelete() and
during the subsequent remove/move flow, the code logs a generic error and then
rethrows a new StorageContainerException without preserving the original caught
IOException at that log site.
*Current behavior:*
- delete flow catches IOException
- logs a generic move-failure message
- triggers volume scan and throws a new StorageContainerException
- the original filesystem cause is not logged in that catch block
*Why this is a problem:*
This makes production diagnosis harder. In the reviewed case, the logs showed
that the move failed, but not why it failed, forcing the investigation to infer
possible causes rather than observe the underlying I/O error directly.
*Proposed fix:*
- include the original IOException in the error log before rethrow
- include enough context in the log to identify container ID and
source/destination paths
- do not change delete semantics in this ticket
*Acceptance criteria:*
- delete failure logs include the original exception stack trace
- logs contain sufficient context to distinguish missing directory, stale
destination, permissions, or other filesystem issues
- tests updated if practical
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
