Mounting a filesystem twice with unionfs like so causes filesystem deadlocks when files are modified on top of unionfs: #!/bin/sh mkdir pristine cat > supfile <<EOF *default host=cvsup1.freebsd.org *default base=/FreeBSD/sup *default prefix=$PWD/FreeBSD *default release=cvs *default delete use-rel-suffix *default compress EOF csup supfile mkdir touched union mount -t unionfs pristine union mount -t unionfs touched union cd union make buildworld -j4 ===== Any value of -j above -j1 causes filesystem deadlocks; processes like make will block when trying to access directory information -- it's worse for UFS than ZFS because it seems like some structures -- in particular the UFS_DIRHASH -- might be locked indefinitely causing the entire filesystem to become unusable. In either case I've seen the filesystem will prevent rebooting from completing cleanly as there are processes waiting on filesystem resources to become available. This can also be stimulated via freenas builds like so: sh build/do_build.sh -U LORs have also been identified within unionfs around when the deadlock occurs, which might suggest that incorrect locking is preventing unionfs from releasing resources when a [soft] failure occurs. I don't have the LORs right now, but I'm hunting them down in my logs.. How-To-Repeat: See decomposed example above.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Please try this new patch that solves a dead lock issue of unionfs. # cd /usr/src/ # patch -p3 < attached_file -- ONGS Inc. Ozawa <ozawa@ongs.co.jp> WWW: http://www.ongs.co.jp/
I can verify this patch absolutely fixes all the issues I was experiencing. M= y problem was random deadlocking behavior, forcing me to reboot the system m= anually, when I started/stopped jails using unionfs and/or starting services= inside said jails, under FreeBSD 9 RELEASE.=
State Changed From-To: open->closed Committed. Thanks!