VERIFY(zio->io_type != ZIO_TYPE_WRITE || spa_writeable(spa)) failed

[DeHackEd]

# zpool import poolWithDedup -o readonly=on

VERIFY(zio->io_type != ZIO_TYPE_WRITE || spa_writeable(spa)) failed
SPLError: 18263:0:(zio.c:2468:zio_vdev_io_start()) SPL PANIC
SPL: Showing stack for process 18263
Pid: 18263, comm: z_null_iss/0 Tainted: P           ---------------    2.6.32-358.el6.x86_64 #1
Call Trace:
 [] ? spl_debug_dumpstack+0x27/0x40 [spl]
 [] ? spl_debug_bug+0x81/0xd0 [spl]
 [] ? zio_vdev_io_start+0x2d1/0x2e0 [zfs]
 [] ? zio_execute+0xb3/0x130 [zfs]
 [] ? taskq_thread+0x218/0x4b0 [spl]
 [] ? thread_return+0x4e/0x76e
 [] ? default_wake_function+0x0/0x20
 [] ? taskq_thread+0x0/0x4b0 [spl]
 [] ? kthread+0x96/0xa0
 [] ? child_rip+0xa/0x20
 [] ? kthread+0x0/0xa0
 [] ? child_rip+0x0/0x20

ZFS version d9b0ebb
Commit Date: Sun Feb 24 11:22:07 2013 +0000

Pool is a single ~500G partition off a 1T disk with dedup enabled.

ryao thinks this is from a corrupted checksum on the disk. If this is the case then mounting the pool read/write might fix the problem and make it impossible to reproduce the issue. Then again I'll need to reboot the host anyway.

[ryao]

I spoke to @DeHackEd about this in IRC. I believe that there is a bad checksum in metadata used during the import, which triggers a read of the good copy and a repair write to correct the bad copy. The failure occurred because readonly imports were not considered when writing zio_vdev_io_start(). There is no check for this condition before the VERIFY() statement, so a backtrace will be printed and the thread will halt. There appears to be related code that immediately follows the VERIFY() statement, but that handles a different circumstance.

I can write a fix for this, but I am taking things easy today, so that will wait a few hours. Feel free to ping me in IRC if I don't have a fix by tomorrow.

[ryao]

@DeHackEd There is a chance that the same patch for #1333 will also work here. Would you try ryao/zfs@459d979 and let me know if it solves this problem?