Date: Thu, 19 Jul 2018 14:36:41 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 229887] zfs quota related panic: solaris assert: 0 == dmu_tx_assign(tx, TXG_WAIT), Message-ID: <bug-229887-3630-fu75CKUW2u@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-229887-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-229887-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=3D229887 Alexander Motin <mav@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |avg@FreeBSD.org --- Comment #1 from Alexander Motin <mav@FreeBSD.org> --- The first panic indeed looks like combination of r334810 making dmu_tx_assi= gn() errors fatal and quota overflow causing that. We need to handle those erro= rs somehow. About second panic I am not sure, but I found such an interesting comment a= bove zfs_unlinked_add(): * When dealing with the unlinked set, we dmu_tx_hold_zap(), but we * don't specify the name of the entry that we will be manipulating. We * also fib and say that we won't be adding any new entries to the * unlinked set, even though we might (this is to lower the minimum file * size that can be deleted in a full filesystem). So on the small * chance that the nlink list is using a fat zap (ie. has more than * 2000 entries), we *may* not pre-read a block that's needed. * Therefore it is remotely possible for some of the assertions * regarding the unlinked set below to fail due to i/o error. On a * nondebug system, this will result in the space being leaked. Curios whether it can be the case here. --=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-229887-3630-fu75CKUW2u>