[Bug 222734] 11.1-RELEASE kernel panics while importing ZFS pool

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222734

--- Comment #4 from Andriy Gapon <avg at FreeBSD.org> ---
(In reply to Ben RUBSON from comment #3)

Not sure what's scary... (at least, scarier than before).

But let me try to clarify the problem first.
A bit flip happened in RAM (non-ECC) and some corrupted (meta-)data got written
to disk.  It happened to be a block pointer within an indirect block.  For ZFS
the indirect block looked totally valid as its checksum was calculated after
the bit flip.  So, ZFS had no reason to distrust the block pointers in the
block.
Still, the newer ZFS does some additional validation (sanity checking) of those
block pointers while the older ZFS fully trusted them to be correct.  A corrupt
block pointer would typically result in a crash later on.  And such a crash is
hard(-er) to debug, that's why the extra checks were added.  In some cases the
corruption would be almost benign, so things would appear to be okay.  In this
case, the block pointer was actually a hole block pointer and the corruption
was of the almost benign variety.
So, really, the culprit here was faulty RAM.  If your data gets corrupted in
memory, you have corrupted data and there is no way ZFS can help with that.  If
your metadata gets corrupted in memory, then ZFS might be able to detect that
and bail out early, or it can fail to detect the problem and crash later on, or
it can even try to read a wrong block, but then the checksum error is the most
likely outcome.
The usual advice applies, use ECC memory and have backups.
Even on a system with ECC memory some hardware can corrupt memory by writing to
wrong location via DMA, even on a system with reliable hardware there still can
be a kernel (driver) bug that would corrupt memory contents, etc.

-- 
You are receiving this mail because:
You are the assignee for the bug.