Quoting Stephan Budach <[email protected]> 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/[email protected],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. _______________________________________________ OmniOS-discuss mailing list [email protected] http://lists.omniti.com/mailman/listinfo/omnios-discuss
