[OpenIndiana-discuss] System Panics after deleting zvol (Jim Klimov)

[Jim Klimov]

>> To recap, your system uses dedup and has 12Gb RAM, and apparently
>> the removal of the zvol requires it to walk the DDT blocks to find

And, also, like other posters suggested - it might be beneficial for 
your configuration to migrate into a non-deduped setup by copying
your data to another new pool and recreating your pool from scratch.
This might also be the faster solution to return your storage box
into proper online service. Note that if your current system did
employ the dedup successfully, your data on the undeduped target
pool will blow up to use more space, so the new pool might need
to use more and/or larger disks.

You can use "dd" for zvols and "rsync" for filesystem datasets, if
you don't have any snapshots to "zfs send" from the pool while it
is mounted read-only (a year ago I had problems sending from such
a readonly pool, because intermittent "zfs hold" failed; I think
the problem was addressed in more recent builds of illumos and OI).

If you want to recreate the snapshot/clone structure on the target
pool, you can somewhat emulate this with rsync, by copying from
the /$pool/$dataset/.zfs/snapshots/$snapname/ directories with
"rsync -cavPHK --delete-after ./ remote:/targetpath/" and making
the snapshots or clones manually on the target when appropriate
between such rsync runs. For slow net and compressible data you
might also benefit from "rsync -z" for gzip compression.

I am not sure you can process differences of zvols as cleanly if
you need the history; maybe rsync of the zvols' character device
files can help in this case...

HTH,
//Jim Klimov