ZFS corrupt DVA panic: can it be fixed?

[Zaphod Beeblebrox]

Before this problem, I had a few crashes... which may have been hardware
related.  The hardware is (I think) fixed, but this problem remains.  My
searches seem to indicate that this has happened to other people.

... I've pasted here only the first two lines of the last 3 panic's I've
had.

panic: dva_get_dsize_sync(): bad DVA 1573890:1587590144
#3 0xffffffff822b8b01 at dva_get_dsize_sync+0xb1
panic: dva_get_dsize_sync(): bad DVA 1573890:1587590144
#3 0xffffffff822b8b01 at dva_get_dsize_sync+0xb1
panic: dva_get_dsize_sync(): bad DVA 1573890:1587590144
#3 0xffffffff822b8b01 at dva_get_dsize_sync+0xb1

I gather that the machine runs until something causes the kernel to
encounter the corrupt DVA.  I gather from reading stuff that this is part
of the structure that holds free space on the drive.  Since the numbers are
the same in each panic, I'm assuming that each panic is encountering the
same one.  This is also the panic that is not dumping properly to either
USB or spinning disk.

I have zdb -uuumcD running right now.  It seems to estimate that it's going
to take an awfully long time, but the estimation might be broken because
it's on 159 of 171 of whatever it's reading.

Now... question: is this fixable?  Can I just mark off the space as
unusable, maybe?

Since this has happened to more than one person, I gather it's a
significant hole in the claim that ZFS is crashproof (or that it doesn't
need repair after crashing).

Maybe this check can be added to scrub (or scrub + an option)?  Or maybe
when we run across it, we fix it?  Does fixing it (in the theoretical
sense) require knowing all the free space on the drive?  Doesn't scrub do
that?