Skip to content

Sync ZVOLs block cloning conditions with file systems#18315

Closed
amotin wants to merge 2 commits intoopenzfs:masterfrom
amotin:zvol_clone_key
Closed

Sync ZVOLs block cloning conditions with file systems#18315
amotin wants to merge 2 commits intoopenzfs:masterfrom
amotin:zvol_clone_key

Conversation

@amotin
Copy link
Member

@amotin amotin commented Mar 12, 2026

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Quality assurance (non-breaking change which makes the code more robust against bugs)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
  • Documentation (a change to man pages or other documentation)

Checklist:

@amotin amotin requested a review from ixhamza March 12, 2026 15:43
@amotin amotin added the Status: Code Review Needed Ready for review and testing label Mar 12, 2026
@amotin amotin requested a review from behlendorf March 12, 2026 18:39
@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Mar 12, 2026
amotin added 2 commits March 12, 2026 16:00
Somehow during block cloning porting from file systems was missed
the check for identical encryption keys.  As result, blocks cloned
between unrelated ZVOLs produced authentication errors on later
reads.  Having same or different encryption root does not matter.

This patch copies dmu_objset_crypto_key_equal() call from FS side.

Signed-off-by: Alexander Motin <alexander.motin@TrueNAS.com>
While technically its not a problem to clone between ZVOLs with
different properties, it might create expectation of new properties
being applied during data move, while actually it won't happen.
For copies and checksum it may mean incorrect safety expectations.
For dedup, compression and special_small_blocks -- performance and
space usage.

This is a replica of openzfs#18180 from FS.

Signed-off-by: Alexander Motin <alexander.motin@TrueNAS.com>
@github-actions github-actions bot removed the Status: Accepted Ready to integrate (reviewed, tested) label Mar 12, 2026
@amotin amotin added the Status: Accepted Ready to integrate (reviewed, tested) label Mar 12, 2026
behlendorf pushed a commit that referenced this pull request Mar 13, 2026
While technically its not a problem to clone between ZVOLs with
different properties, it might create expectation of new properties
being applied during data move, while actually it won't happen.
For copies and checksum it may mean incorrect safety expectations.
For dedup, compression and special_small_blocks -- performance and
space usage.

This is a replica of #18180 from FS.

Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <alexander.motin@TrueNAS.com>
Closes #18315
@amotin amotin deleted the zvol_clone_key branch March 13, 2026 13:33
amotin added a commit to truenas/zfs that referenced this pull request Mar 13, 2026
While technically its not a problem to clone between ZVOLs with
different properties, it might create expectation of new properties
being applied during data move, while actually it won't happen.
For copies and checksum it may mean incorrect safety expectations.
For dedup, compression and special_small_blocks -- performance and
space usage.

This is a replica of openzfs#18180 from FS.

Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <alexander.motin@TrueNAS.com>
Closes openzfs#18315
bugclerk pushed a commit to truenas/zfs that referenced this pull request Mar 13, 2026
While technically its not a problem to clone between ZVOLs with
different properties, it might create expectation of new properties
being applied during data move, while actually it won't happen.
For copies and checksum it may mean incorrect safety expectations.
For dedup, compression and special_small_blocks -- performance and
space usage.

This is a replica of openzfs#18180 from FS.

Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <alexander.motin@TrueNAS.com>
Closes openzfs#18315
(cherry picked from commit c18cab6)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Status: Accepted Ready to integrate (reviewed, tested)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants