Bug #4252
kernel panic with zfs send/receive while upgrading to a vdev with larger ashift
0%
Description
Too much downtime... after upgrading sd.conf with http://wiki.illumos.org/display/illumos/List+of+sd-config-list+entries+for+Advanced-Format+drives
I attempted migration of my dpool which was on a Samsung 840 as follows:
1. first I attached a churning rusty drive and let complete a resilver
2. then I detached the SSD
3. created a new 'tpool' on the SSD after rebooting with sd.conf updated and verified that the blocksize was indeed 8192
4. snapshotted and tried a few times a simple 'zfs send -R dpool@migrate8K1 |zfs receive -dvu tpool'
5. after two or three reboots I realised there were problems so I manually recreated part of my file system structure and copied the bulk with rsync
6. thought I would try zfs send/receive again with my zones, but no dice, but at least this time I got a dump (as follows):
tail of ::msgbuf
panic[cpu3]/thread=ffffff02d90dcc40: assertion failed: dn->dn_datablkshift != 0, file: ../../common/fs/zfs/dmu_tx.c, line: 638 ffffff000fc9c5b0 genunix:process_type+1623c0 () ffffff000fc9c640 zfs:dmu_tx_hold_free+2a0 () ffffff000fc9c6c0 zfs:dmu_free_long_range_impl+9f () ffffff000fc9c730 zfs:dmu_free_long_range+62 () ffffff000fc9c7c0 zfs:dmu_object_reclaim+dc () ffffff000fc9c850 zfs:restore_object+111 () ffffff000fc9c9d0 zfs:dmu_recv_stream+4b2 () ffffff000fc9cbc0 zfs:zfs_ioc_recv+1e7 () ffffff000fc9cc70 zfs:zfsdev_ioctl+4ff () ffffff000fc9ccb0 genunix:cdev_ioctl+39 () ffffff000fc9cd00 specfs:spec_ioctl+60 () ffffff000fc9cd90 genunix:fop_ioctl+55 () ffffff000fc9ceb0 genunix:ioctl+9b () ffffff000fc9cf00 unix:brand_sys_syscall32+272 () syncing file systems...
::stack
> ::stack vpanic() 0xfffffffffbdf28a8() dmu_tx_hold_free+0x2a0(ffffff02e02c7600, b371, 0, c00) dmu_free_long_range_impl+0x9f(ffffff2cd2101780, ffffff28d9d3a3f8, 0, ffffffffffffffff) dmu_free_long_range+0x62(ffffff2cd2101780, b371, 0, ffffffffffffffff) dmu_object_reclaim+0xdc(ffffff2cd2101780, b371, 13, 1e00, 2c, a8) restore_object+0x111(ffffff000fc9c910, ffffff2cd2101780, ffffff000fc9c8a0) dmu_recv_stream+0x4b2(ffffff000fc9caf0, ffffff228b436700, ffffff000fc9cb70, 8, ffffff7c4b5dc150) zfs_ioc_recv+0x1e7(ffffff7c4b5db000) zfsdev_ioctl+0x4ff(a900000000, 5a1b, 8045380, 100003, ffffff02d927d4e8, ffffff000fc9ce58) cdev_ioctl+0x39(a900000000, 5a1b, 8045380, 100003, ffffff02d927d4e8, ffffff000fc9ce58) spec_ioctl+0x60(ffffff02e55f5f00, 5a1b, 8045380, 100003, ffffff02d927d4e8, ffffff000fc9ce58) fop_ioctl+0x55(ffffff02e55f5f00, 5a1b, 8045380, 100003, ffffff02d927d4e8, ffffff000fc9ce58) ioctl+0x9b(3, 5a1b, 8045380) sys_syscall32+0x1f7()
should mention that I'm running with the latest commits, up to and including:
commit 8181b438236881e6d31f7155101c85c011a9b6bb (upstream/master, origin/master, Author: Garrett D'Amore <garrett@openindiana.(none)> Date: Wed Oct 16 14:32:48 2013 -0700 4217 Writes to MSI-X table should be DWords, not QWords Reviewed by: Robert Mustacchi <rm@joyent.com> Reviewed by: Steven Hartland <killing@multiplay.co.uk> Reviewed by: Marcel Telka <marcel@telka.sk> Approved by: Dan McDonald <danmcd@nexenta.com>
on a side-note, it would be great if the process of upgrading the blocksize could be automated inline, for instance as an option to 'zpool upgrade'...
Related issues
Updated by Richard PALO over 7 years ago
- Status changed from New to Feedback
sorry, duplicate of #4188
Updated by Marcel Telka over 7 years ago
- Category set to zfs - Zettabyte File System
- Status changed from Feedback to Rejected