[Bug 229887] zfs quota related panic: solaris assert: 0 == dmu_tx_assign(tx, TXG_WAIT),

[bugzilla-noreply at freebsd.org]

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

Alexander Motin <mav at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |avg at FreeBSD.org

--- Comment #1 from Alexander Motin <mav at FreeBSD.org> ---
The first panic indeed looks like combination of r334810 making dmu_tx_assign()
errors fatal and quota overflow causing that.  We need to handle those errors
somehow.

About second panic I am not sure, but I found such an interesting comment above
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.

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