Date: Thu, 22 Jun 2017 11:38:37 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 220203] [zfs] [panic] in dmu_objset_do_userquota_updates on mount Message-ID: <bug-220203-8-Q1iEkXV8NY@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-220203-8@https.bugs.freebsd.org/bugzilla/> References: <bug-220203-8@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=3D220203 --- Comment #5 from neovortex@gmail.com --- (In reply to Andriy Gapon from comment #4) Sadly I've already nuked the filesystem and restored it from backup. If it happens again (already twice this week, so if the SAS2008 controller was a = red herring I'd expect to see it again pretty soon) I'll definitely run this and save the output. The filesystem that got corrupt in both cases (different jails in each instance) neither of them had any real load on them. If it was calculating wrong (bit flip in RAM that ECC couldn't detect, or CPU error, although I actually swapped over the CPU when I dropped from 2 sockets to 1 socket, so pretty much only mainboard and RAM left at this point) I'd have expected to see this occur more often on actual data rather than on metadata. There's a= lso other pools that have a _LOT_ more writes than the SSD pool, so I'd have expected it to appear there too, but it scrubs clean (all ~9.5TB worth). Mirrored disks having identical layout would I guess match if it was TRIM though. As an aside, found the SAS2008 firmware version in case it's relevant: mps0: Firmware: 15.00.00.00, Driver: 21.01.00.00-fbsd --=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-220203-8-Q1iEkXV8NY>