I've just got:

/mnt: write failed, file system is full
Aug  8 23:59:51  /netbsd: uid 0, pid 447, command cp, on /mnt: file system full
uvm_fault(0xc4b32600, 0, 0, 1) -> 0xe
kernel: page fault trap, code=0 
Stopped in pid 447.1 (cp) at    netbsd:ffs_full_fsync+0x1b:     movl    0x8(%eax),%eax
db> tr
ffs_full_fsync(c4c9db0c,0,0,4,0) at netbsd:ffs_full_fsync+0x1b
ffs_fsync(c4c9db0c,c4b679dc,0,c0345a5f,0) at netbsd:ffs_fsync+0x3c
VOP_FSYNC(c4b743e4,ffffffff,5,0,0) at netbsd:VOP_FSYNC+0x58
vinvalbuf(c4b743e4,1,ffffffff,c4b679dc,0) at netbsd:vinvalbuf+0x52
vclean(c4b743e4,8,c4b679dc,c03524ff,c4b75370) at netbsd:vclean+0x80
vgonel(c4b743e4,c4b679dc,c4b743e4,c05654e0,c4b743e4) at netbsd:vgonel+0x46
vrecycle(c4b743e4,0,c4b679dc,0,c4b7441c) at netbsd:vrecycle+0x20
ufs_inactive(c4c9dc64,c095d000,c4c9dc8c,c0565420,c4c47058) at netbsd:ufs_inactive+0x180
VOP_INACTIVE(c4b743e4,c4b679dc,c4c9dde0,c02f2d2b,c4c9dcd8) at netbsd:VOP_INACTIVE+0x2e
vput(c4b743e4,c4b55400,ffffffff,2,c4c9de3c) at netbsd:vput+0xa2
ufs_makeinode(61a0,c4c47058,c4c9de9c,c4c9deb0,c4c47058) at netbsd:ufs_makeinode+0x35e
ufs_mknod(c4c9de3c,c4b679dc,c4c9df80,c034a9ea,0) at netbsd:ufs_mknod+0x2d
VOP_MKNOD(c4c47058,c4c9de9c,c4c9deb0,c4c9ded4,c4b35780) at netbsd:VOP_MKNOD+0x3b
sys_mknod(c4b35780,c4c9df80,c4c9df78,c03b817b,8064048) at netbsd:sys_mknod+0x1dd
syscall_plain(1f,1f,1f,1f,804a863) at netbsd:syscall_plain+0xab
db>

The 'file system full' is expected, the filsystem isn't very big at all.
# mount /dev/vnd0a /mnt                                                         # df -ki /mnt
Filesystem  1K-blocks Used Avail Capacity iused ifree %iused  Mounted on
/dev/vnd0a         10    1     8    11%       1   285    0%   /mnt
# cp -R /dev /mnt

I'm not actually sure whether it runs out of inodes or space to expand
the directory first, but it shouldn't panic.

The panic happens in the code:

	if (vp->v_type == VBLK &&
	    vp->v_specmountpoint != NULL &&
	    (vp->v_specmountpoint->mnt_flag & MNT_SOFTDEP))
		softdep_fsync_mountdev(vp);

because v_specmountpoint is actually v_specinfo->si_mountpoint and
v_specinfo is itself NULL.  I don't know enough about this code to
know whether just trapping v_specinfo == NULL is enough.

ddb gives the inode state as:

db> show vnode/f  0xc4b743e4
OBJECT 0xc4b743e4: locked=0, pgops=0xc06beed0, npages=0, refs=0
  PAGES <pg,offset>:

VNODE flags 100<XLOCK>
mp 0xc095b200 numoutput 0 size 0x0
data 0xc4b75370 usecount 0 writecount 0 holdcnt 0 numoutput 0
type VBLK(3) tag VT_UFS(1) mount 0xc095b200 typedata 0x0
clean bufs:
dirty bufs:
db> 

	David

-- 
David Laight: david@l8s.co.uk