Date: Mon, 09 Oct 2017 07:09:28 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 222734] 11.1-RELEASE kernel panics while importing ZFS pool Message-ID: <bug-222734-3630-0bwrAhqucJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-222734-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-222734-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222734 --- Comment #4 from Andriy Gapon <avg@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 wri= tten 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 t= hose block pointers while the older ZFS fully trusted them to be correct. A cor= rupt 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 t= his 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 th= at 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 m= ost 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 writin= g 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222734-3630-0bwrAhqucJ>