nullfs/quota/jail interaction

[Charles Sprickman]

Hi all,

I know nullfs is not to be relied upon, but I did hit an interesting bug 
the other day, and I was wondering if I should bother with a PR or not.

In short, doing the following seems to dirty the partition and leave the 
machine in a state where a hard reset is required to recover.  This is 
-stable from 1/4/06.

-start a jail within a partition dedicated to jails, in my case it looks 
like:
  /jails
  /jails/jail1
  /jails/jail2
  etc...

-use nullfs to link the host's ports tree into the jail:
  mount_nullfs /usr/ports /jails/jail1/usr/ports

-enable quotas for the /jails partition

-stop the jails and run quotacheck to make sure everything is consistent
  quotacheck -v /jails

At that point, the quotacheck command seems to deadlock on something.  The 
process is not interruptible (ie: CTRL-C, CTRL-Z do not do anything but 
echo) even with a "kill -9" from the host.

Any subsequent command that attempts to read anything from that partition 
will also hang as above.

If a shutdown is issued, that does not kill off any of the deadlocked 
processes and the machine must be manually reset (something of a pain if 
it's remote).

In order to get a clean boot I had to remove all jail startup commands 
from rc.conf and make sure nothing else (like syslog) was trying to do 
anything in /jails.  Even then, the background fsck eventually deadlocked 
as well.  I had reboot once more with /jails commented out of fstab and 
then run the fsck manually to recover.

Should I write this up and send it in case one day someone decides to fix 
nullfs?

I'm also wondering about the seperate issue of having some deadlocked 
process not allowing the machine to reboot - I've seen similar reports of 
this behaviour with various other less-than-stable filesystems like vfs. 
It would be nice to have some way of telling the kernel "please stop 
waiting on this disk, it's not coming back, it's futile, please just 
reboot".

Thanks,

Charles