NAS-133555 / 24.04.3 / Block remap for cloned blocks on device removal#286
Merged
amotin merged 1 commit intostable/dragonfishfrom Mar 26, 2025
Merged
NAS-133555 / 24.04.3 / Block remap for cloned blocks on device removal#286amotin merged 1 commit intostable/dragonfishfrom
amotin merged 1 commit intostable/dragonfishfrom
Conversation
When after device removal we handle block pointers remap, skip blocks that might be cloned. BRTs are indexed by vdev id and offset from block pointer's DVA[0]. So if we start addressing the same block by some different DVA, we won't get the proper reference counter. As result, we might either remap the block twice, that may result in assertion during indirect mapping condense, or free it prematurely, that may result in data overwrite, or free it twice, that may result in assertion in spacemap code. Signed-off-by: Alexander Motin <mav@FreeBSD.org> Sponsored by: iXsystems, Inc. Fixes openzfs#15604
bugclerk
changed the title
ixhamza
approved these changes
Mar 26, 2025
|
This PR has been merged and conversations have been locked. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When after device removal we handle block pointers remap, skip blocks that might be cloned. BRTs are indexed by vdev id and offset from block pointer's DVA[0]. So if we start addressing the same block by some different DVA, we won't get the proper reference counter. As result, we might either remap the block twice, that may result in assertion during indirect mapping condense, or free it prematurely, that may result in data overwrite, or free it twice, that may result in assertion in spacemap code.
While we don't plan to release another version of Dragonfish, this branch is shared with 13.3, fix for which we might release.
How Has This Been Tested?
Written and cloned a file on a pool of several vdevs. Removed one of vdevs. Overwritten each 128th block of the file to trigger block pointers remap. Run
zdbon the pool and observed it crashing due to incorrect block reference counting. Applied the patch and observedzdbpassing clean. I wonder if it may also fix some space leaks periodically reported byzdbafterztest.Types of changes
Checklist:
Signed-off-by.