I am seeing this panic message: Panic: zfs_fuid_create cpuid=1 KDB: enter: Panic [thread pid2819 tid 100215] stopped at kdb_enter+0x3a:movl $,kdb_why (this is from hand-written notes, and may not be exact) zfs is causing a panic when I try to write a file with a 64 bit "nobody" UID. This occurs from a tar, from cp, and from rsync, and any other attempt to write a file owned by UID 4294967294. This UID originates from the anonymous (nobody) UID -2 on a windows server. When this UID is written to a unix NFS server, it becomes 4294967294. More details on this UID origination are at http://blogs.msdn.com/sfu/pages/who-s-4294967294.aspx Other filesystems don't have a problem with this 64bit UID. Ideally ZFS shouldn't either, but if we don't want to support 64bit UIDs, then we should find something more useful to do than generating a panic. Fix: Patch attached with submission follows: How-To-Repeat: extract the files from the attached tar file onto a zfs filesystem. Due to a browser bug, the file is named with .txt, but it IS a tar file.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Responsible Changed From-To: freebsd-fs->pjd Over to maintainer.
I'm seeing that same bug. Not sure exactly what file tripped it, but this is what gets dumped to the serial console: panic: zfs_fuid_create cpuid = 0 KDB: enter: panic [thread pid 1063 tid 100162 ] Stopped at kdb_enter+0x3d: movq $0,0x678340(%rip) db>
Responsible Changed From-To: pjd->freebsd-fs With pjd's permission, reassing ZFS-related PRs to freebsd-fs. To submitter: did the suggested patch fix the problem?
I applied the patch and removed the debugging options from my 8-STABLE kernel and have not seen this issue since.
State Changed From-To: open->feedback Could you try this patch: http://people.freebsd.org/~pjd/patches/zfs_znode.h.patch
State Changed From-To: feedback->closed Duplicate of 132337, which is now fixed in HEAD.
Responsible Changed From-To: freebsd-fs->pjd I'll take this one.