[OmniOS-discuss] ZFS panic when unlinking a file

[Omen Wild]

Quoting Stephan Budach <stephan.budach at JVM.DE> on Tue, Sep 15 06:59:
>
> Am 15.09.15 um 03:46 schrieb Paul B. Henson:
> >>From: Omen Wild
> >>Sent: Monday, September 14, 2015 3:10 PM
> >>
> >>Mostly we are wondering how to clear the corruption off disk and worried
> >>what else might be corrupt since the scrub turns up no issues.
> >While looking into possible corruption from the recent L2 cache bug it seems
> >that running 'zdb -bbccsv' is a good test for finding corruption as it looks
> >at all of the blocks and verifies all of the checksums.

I have kicked that off. I expect it will take a while as the pool has
15.6TB of data.

> As George Wilson wrote on the ZFS mailing list: " Unfortunately, if the
> corruption impacts a data block then we won't be able to detect it.". So, I
> am afarid apart from metadata and indirect blocks corruption, there's no way
> to even detect a corruption inside a data block, as the checksum fits.

We have no l2arc on this machine, so I don't believe 6214 will impact
us. When the corruption first manifest itself we were running an
update from July (2015-07-20T14:15:58) with
pkg://omnios/system/file-system/zfs@0.5.11,5.11-0.151014:20150402T175233Z

> I think, the best one can do is to run a scrub and act on the results of
> that. If scrub reports no errors, one can live with that or one would need
> to think of options to reference the data with known, good data from that
> pool, e.g. from a backup prior to 6214 having been introduced, but depending
> on the sheer amount of data or the type of it, that might not be even
> possible.

The 'zpool scrub' was clean, no errors. unlinking the file still causes
the panic. I will report the results of the zdb when it finishes.

Thanks for the ideas.