incusd/storage/zfs: Fix missing incus:content_type after cloning a custom volume #2180
Conversation
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
added 2 commits
June 6, 2025 09:21
Signed-off-by: Stuart Espey <stuart.espey@mactrix.com>
…stom volume When creating a VolumeTypeCustom volume with the ZFS driver the incus:content_type user property is used to capture the ContentType. When recovering the storage pool or the volume, this content_type is used to disambiguate the volume if it is using zfs.block_mode. Unfortunately, when cloning the volume using zfs.block_copy the content_type is lost and the filesystem block mode volumes are imported as block mode volumes instead. The fix corrects by regenerating the content_type after cloning when it is still known. A test has been added to storage_driver_zfs.sh which tests the issue, and the fix. Signed-off-by: Stuart Espey <stuart.espey@mactrix.com>
stgraber
approved these changes
Jun 6, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 creating a volume of type
VolumeTypeCustomwith the ZFS driver theincus:content_typeuser propertyis used to capture the
ContentType. When recovering the storage pool or the volume, thiscontent_typeis used to disambiguate the volume if it is usingzfs.block_mode.Unfortunately, when cloning the volume using
zfs.clone_copymode thecontent_typeis lostand the filesystem block mode volumes are imported as block mode volumes instead.
The fix corrects by regenerating the content_type during the clone when it is still known.
A test has been added to storage_driver_zfs.sh which reproduces the issue, and confirms the fix.