illumos gate

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'...