Date: Fri, 30 Mar 2018 21:31:23 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 219972] Unable to zpool export following some zfs recv Message-ID: <bug-219972-3630-XdXyOz2JJH@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219972-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-219972-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=3D219972 --- Comment #11 from pfribeiro@gmail.com --- (In reply to Matthias Pfaller from comment #10) I just installed a fresh 11.1-RELEASE (r321309) and can see that the issue I reported is still there. I don't seem to recall having had a problem with reboot getting stuck. It's just that rebooting is necessary to get the pool unstuck. Following the next boot it is in some kind of dormant state, (UNAVAIL?) but can be exported successfully. I would like to add that in my `dtrace` output the call trace is exactly li= ke that of Matthias. I've tried playing with cpuset to change the cores available to the schedul= er, as well as on a per process basis, but couldn't work around the problem with zfs export. For the lack of a better workaround, I've added 'dd if=3D/dev/z= ero of=3Ddev/null' around my usage of zpool export as follows: dd if=3D/dev/zero of=3D/dev/null bs=3D1024k & PIDDD=3D$! zpool export -f backup kill -9 $PIDDD First I spawn a concurrent dd, and then once the export terminates I kill i= t. In this way I don't seem to get a busy pool even when doing zfs import/expo= rt many, many times after the zfs recv. Perhaps this can give someone a hint of where the problem may lie. Would be nice to get a bug fix, though :) --=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-219972-3630-XdXyOz2JJH>