Please sign in to comment.
panic in removal_remap test on 4K devices
If the zfs_remove_max_segment tunable is changed to be not a multiple of the sector size, then the device removal code will malfunction and try to create mappings that are smaller than one sector, leading to a panic. On debug bits this assertion will fail in spa_vdev_copy_segment(): ASSERT3U(DVA_GET_ASIZE(&dst), ==, size); On nondebug, the system panics with a stack like: metaslab_free_concrete() metaslab_free_impl() metaslab_free_impl_cb() vdev_indirect_remap() free_from_removing_vdev() metaslab_free_impl() metaslab_free_dva() metaslab_free() Fortunately, the default for zfs_remove_max_segment is 1MB, so this can't occur by default. We hit it during this test because removal_remap.ksh changes zfs_remove_max_segment to 1KB. When testing on 4KB-sector disks, we hit the bug. This change makes the zfs_remove_max_segment tunable more robust, automatically rounding it up to a multiple of the sector size. We also turn some key assertions into VERIFY's so that similar bugs would be caught before they are encoded on disk (and thus avoid a panic-reboot-loop). Reviewed-by: Sean Eric Fagan <email@example.com> Reviewed-by: Pavel Zakharov <firstname.lastname@example.org> Reviewed-by: Serapheim Dimitropoulos <email@example.com> Reviewed-by: Sebastien Roy <firstname.lastname@example.org> Reviewed-by: Brian Behlendorf <email@example.com> Signed-off-by: Matthew Ahrens <firstname.lastname@example.org> External-issue: DLPX-61342 Closes #8893
- Loading branch information...
Showing with 59 additions and 14 deletions.