I have 82GB UFS image file (ufs-snapshot.img) mounted on some directory ufs-snapshot.mount. (mount /dev/`mdconfig -a -t vnode -f ufs-snapshot.img` ufs-snapshot.mount) Both original file ufs-snapshot.img and ufs-snapshot.mount are on the same ZFS disk. Command 'cp -R ufs-snapshot.mount/usr other-dir/' hanged in the middle with DL+ status: $ ps ax | grep cp 73635 10 DL+ 0:12.19 cp -R ufs-snapshot.mount/usr other-dir/ 'top' shows it in vnread state: 73635 root 1 20 0 10084K 2672K vnread 1 0:12 0.00% cp When I ran 'ls' in the same mounted directory it hanged too with D+ status: $ ps ax | grep ls 75882 2 D+ 0:00.00 ls ufs-snapshot.mount/ Subsequent 'ls' of this ZFS disk's top directory hangs in the same way. And after few hours system freezes. It appears that cp -R creates the gridlock condition when it copies from UFS contained in the image file within some ZFS disk into the same ZFS disk.
I just was able to reproduce the same problem after reboot. Need to reboot again now. Since both source (UFS image) of 'cp' and destination directory are on the same ZFS disk, vnread was probably waiting for ZFS lock that was somehow incurred by ongoing writing on the same disk.
Responsible Changed From-To: freebsd-bugs->freebsd-fs
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped