-
Notifications
You must be signed in to change notification settings - Fork 588
HDDS-8118. Fail container delete on non empty chunks dir #4367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a description for this in ozone-default.xml?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to add this config to ozone-default.xml we do not expect outside of debug scenarios to flip this config option.
...ner-service/src/main/java/org/apache/hadoop/ozone/container/common/interfaces/Container.java
Outdated
Show resolved
Hide resolved
...tainer-service/src/main/java/org/apache/hadoop/ozone/container/keyvalue/KeyValueHandler.java
Outdated
Show resolved
Hide resolved
Add a defensive check if the container directory is empty before deleting the container to make sure data is not lost. This may leave a small amount of orphaned data before HDDS-8117 is complete.
duongkame
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Will need another review from someone familiar with container layout to ensure the no-blocks check.
...tainer-service/src/main/java/org/apache/hadoop/ozone/container/keyvalue/KeyValueHandler.java
Show resolved
Hide resolved
Change-Id: I6e76194de6150e1da286cbbacefccd1659bdb2a5
| without using the optimised DAG based pruning approach | ||
| </description> | ||
| </property> | ||
| <property> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any benefit to making this configurable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just in case we want to change the behavior once we are confident of blockCount over presence on disk.
| * @return true if the directory containing blocks is empty | ||
| * @throws IOException | ||
| */ | ||
| public static boolean noBlocksInContainer(KeyValueContainerData |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want to check RocksDB and not chunks on disk. The latter may always be present due to orphaned writes. We only care about committed blocks which have entries in RocksDB.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The likelihood of having blocks written to disk but not in DN RocksDB will go down with https://issues.apache.org/jira/browse/HDDS-8117
We will still have the issue of having blocks on DN that are not on OM which needs to be dealt with separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should check RocksDB in this PR and switch to using the directory check as part of HDDS-8117, or maybe wait until after HDDS-8138. Otherwise we may get some alarming false positives. In order to tell whether the exception is a false positive or not we would need to check RocksDB anyways, so I don't think the error message is useful without a RocksDB check given how the rest of the code works right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The read data is the block. We should work towards making sure blocks are written only if valid, and if they are on disk, we should err towards not cleaning them up. Even with HDDS-8138, I would like to keep this check in place. We can get HDDS-8117 in but while that is being worked on we should check in this fix to avoid any data loss which is the main motivation for this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After offline discussion, we decided to keep this PR as is, since it is better than no check at all. A follow up PR will be coming shortly that will add a RocksDB check and log message here as well to help with debugging.
Change-Id: If410fa45b19cb22b9e3e56a4203be07a4dd36d4a
|
The tests under |
errose28
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix @kerneltime
| * @return true if the directory containing blocks is empty | ||
| * @throws IOException | ||
| */ | ||
| public static boolean noBlocksInContainer(KeyValueContainerData |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should check RocksDB in this PR and switch to using the directory check as part of HDDS-8117, or maybe wait until after HDDS-8138. Otherwise we may get some alarming false positives. In order to tell whether the exception is a false positive or not we would need to check RocksDB anyways, so I don't think the error message is useful without a RocksDB check given how the rest of the code works right now.
|
Thanks for adding this check @kerneltime. The RocksDB check will be added in addition to the directory check in a follow up jira. |
* master: (262 commits) HDDS-8153. Integrate ContainerBalancer with MoveManager (apache#4391) HDDS-8090. When getBlock from a datanode fails, retry other datanodes. (apache#4357) HDDS-8163 Use try-with-resources to ensure close rockdb connection in SstFilteringService (apache#4402) HDDS-8065. Provide GNU long options (apache#4394) HDDS-7930. [addendum] input stream does not refresh expired block token. HDDS-7930. input stream does not refresh expired block token. (apache#4378) HDDS-7740. [Snapshot] Implement SnapshotDeletingService (apache#4244) HDDS-8076. Use container cache in Key listing API. (apache#4346) HDDS-8091. [addendum] Generate list of config tags from ConfigTag enum - Hadoop 3.1 compatibility fix (apache#4374) HDDS-8144. TestDefaultCertificateClient#testTimeBeforeExpiryGracePeriod fails as we approach DST. (apache#4382) HDDS-8151. Support fine grained lifetime for root CA certificate (apache#4386) HDDS-8150. RpcClientTest and ConfigurationSourceTest not run due to naming convention (apache#4388) HDDS-8131. Add Configuration for OM Ratis Log Purge Tuning Parameters. (apache#4371) HDDS-8133. Create ozone sh key checksum command (apache#4375) HDDS-8142. Check if no entries in Block DB for a container on container delete (apache#4379) HDDS-8118. Fail container delete on non empty chunks dir (apache#4367) HDDS-8028. JNI for RocksDB SST Dump tool (apache#4315) HDDS-8129. ContainerStateMachine allows two different tasks with the same container id running in parallel. (apache#4370) HDDS-8119. Remove loosely related AutoCloseable from SendContainerOutputStream (apache#4368) close db connection (apache#4366) ...
(cherry picked from commit 11f3d72)
(cherry picked from commit 11f3d72)
What changes were proposed in this pull request?
Add a defensive check if the container directory is empty before deleting the container to make sure data is not lost. This may leave a small amount of orphaned data before HDDS-8117 is complete.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-8118
How was this patch tested?
Integration test included