Reviewed by: Serapheim Dimitropoulos <[email protected]> Reviewed by: George Wilson <[email protected]>
While expanding stored pools, we ran into a panic using an old pool. Steps to reproduce: jkennedy-origin% sudo zpool create -o version=2 test c2t1d0 jkennedy-origin% sudo cp /etc/passwd /test/foo jkennedy-origin% sudo zpool attach test c2t1d0 c2t2d0 We'll get this panic: ffffff000fc0e5e0 unix:real_mode_stop_cpu_stage2_end+b27c () ffffff000fc0e6f0 unix:trap+dc8 () ffffff000fc0e700 unix:cmntrap+e6 () ffffff000fc0e860 zfs:dsl_scan_visitds+1ff () ffffff000fc0ea20 zfs:dsl_scan_visit+fe () ffffff000fc0ea80 zfs:dsl_scan_sync+1b3 () ffffff000fc0eb60 zfs:spa_sync+435 () ffffff000fc0ec20 zfs:txg_sync_thread+23f () ffffff000fc0ec30 unix:thread_start+8 () The problem is a bad trap accessing a NULL pointer. We're looking for the dp_origin_snap of a dsl_pool_t, but version 2 didn't have that. The system will go into a reboot loop at this point, and the dump won't be accessible except by removing the cache file from within the recovery environment. This impacts any sort of scrub or resilver on version <11 pools, e.g.: zpool create -o version=10 test c2t1d0 zpool scrub test Upstream bug: DLPX-56971 You can view, comment on, or merge this pull request online at: https://github.com/openzfs/openzfs/pull/610 -- Commit Summary -- * 9443 panic when scrub a v10 pool -- File Changes -- M usr/src/uts/common/fs/zfs/dsl_scan.c (5) -- Patch Links -- https://github.com/openzfs/openzfs/pull/610.patch https://github.com/openzfs/openzfs/pull/610.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/610 ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T476cbf523d481025-Md69f66b336211b3735e5dd58 Delivery options: https://openzfs.topicbox.com/groups
