Process stuck in "vnread"

[Konstantin Belousov]

On Wed, Mar 02, 2016 at 09:06:37AM -0800, Maxim Sobolev wrote:
> Konstantin, this is nullfs mounted over UFS and nullfs is pointing over to
> the part of the ZFS tree. I am not sure if it's what you are talking about
> or not.
> 
> 
> storage/builder on /builder (zfs, local, nfsv4acls)
> 
> md0     vnode    3200M  /builder/tmp/sspicd_tmp.ufs
> 
> /dev/md0 on /builder/mnt (ufs, asynchronous, local, noatime)
> /builder/usr/ports-bitbucket on /builder/mnt/usr/ports (nullfs, local)
> 
> So, stuck process refers to file effectively being copied over from
> /builder/mnt/usr/local/share/automake-1.15/compile to
> /builder/usr/ports-bitbucket/SOMETHING/./compile by the process chrooted
> into /builder/mnt, and it could be either in the read path or in the write
> path. However looking at the full kernel side of stack trace of that cp(1),
> I'd say it's probably the latter, as this would have to traverse through
> top level vfs/ufs first, to nullfs layer and then via zfs, none of the last
> two is compiled in so that there is no proper traceback. The nullfs mount
> is used to allow it accessing ZFS tree on the upper level, i.e.
> /builder/usr.
> 
> Unfortunately I cannot find a way to figure out specific system call that
> cp got stuck in. Attempting to attach gdb causes gdb to hang in turn. So
> unless somebody got any other ideas on how to get some useful post-mortem
> debug out of this situation I'll have to restart the box soon to recover it.
> 
> I will put your patch in and see if it helps. I'd also compile nullfs
> statically, so at least if it hits again we have some post-mortem evidence
> to work with.
No, my patch would not help you.

Your problem is hung ZFS.