space_map_max_blksz causes panic, does not work
Setting space_map_max_blksz causes the system to panic:
assertion failed: dmu_object_set_blocksize(sm->sm_os, space_map_object(sm),
newsz, 0, tx) 0 (0x30 0x0), file: ../../common/fs/zfs/space_map.c, line:
space_map_set_blocksize+0x1a2(ffffff01cf350210, 1058, ffffff01df924840)
space_map_write+0x116(ffffff01cf350210, ffffff01cf421d80, 1, ffffff01df924840)
The problem is that dmu_objset_set_blocksize() will fail if the object has
Fix is to ignore failures from dmu_objset_set_blocksize().
This fixes the panic, however space_map_max_blksz now has no effect, because
even though condensing truncates the file, its blocksize still can't be changed
because it used to have multiple blocks.
Fix is for space_map_truncate() to always do space_map_reallocate(). (Note
that given the desire to reset the blocksize to the minimum upon truncation,
there is no alternative to always reallocating. That said, it is not clear to
me why we would care to do that. Spacemaps typically use more than 128K, so it
would seem fine to me if we made space_map_truncate() reallocate if the
blocksize != space_map_max_blksz.)
Now the spacemap blocksize changes. However, metaslab_group_histogram_verify()
breaks, because space_map_truncate() clears the spacemap's histogram.
Fix is to verify the histogram before condensing.
Updated by Electric Monk almost 7 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit b1be2892dd07cf9a97d47ad06334cdc879196aaf Author: Matthew Ahrens <email@example.com> Date: 2014-09-16T19:53:58.000Z 5164 space_map_max_blksz causes panic, does not work 5165 zdb fails assertion when run on pool with recently-enabled spacemap_histogram feature Reviewed by: Christopher Siden <firstname.lastname@example.org> Reviewed by: George Wilson <email@example.com> Reviewed by: Saso Kiselkov <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>