Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Jul 2012 21:46:37 GMT
From:      Josh Beard <josh@hewbert.com>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   kern/170238: ZFS: Panic when deleting data
Message-ID:  <201207282146.q6SLkb5e094916@red.freebsd.org>
Resent-Message-ID: <201207282150.q6SLo1SL016657@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         170238
>Category:       kern
>Synopsis:       ZFS: Panic when deleting data
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jul 28 21:50:00 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Josh Beard
>Release:        9.1-PRERELEASE (Jul 28 2012) amd64
>Organization:
>Environment:
FreeBSD bksys1 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Jul 28 14:16:47 MDT 2012     root@bksys1:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
I posted this to the -stable mailing list, but unfortunately didn't get any feedback there.

When attempting to delete data from a ZFS pool, the system panics.  I completely rebuilt the pools from scratch and experience the same results.

The data itself isn't anything special - it's data that is rsynced nightly from a Mac OS X server for backups.  It doesn't appear to be any specific file(s) that causes it, but it's consistently reproducible.

Do delete, I'm doing a simple "rm -rf"

I run a zpool scrub weekly and it ran a couple of days ago without errors.  This 
issue was present before and after this.  Additionally, I haven't seen 
anything in my logs that indicate failing drives, but I haven't ran a 
long smartctl test for a while.

The system has 16 GB of RAM and I'm not doing anything special for 
tuning ZFS.  The ZFS pool does use compression.

I do have crash dumps enabled, if that helps, and would be happy to 
provide any further detail and information.  Redoing the filesystem is 
an option, as the data is just duplicate backup data and can easily be 
restored.

Here's a a panic log:
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 05
fault virtual address   = 0x160
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff816bbbe6
stack pointer           = 0x28:0xffffff8465f22870
frame pointer           = 0x28:0xffffff8465f22930
code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1646 (rm)
trap number             = 12
panic: page fault
cpuid = 3
KDB: stack backtrace:
#0 0xffffffff8091c836 at kdb_backtrace+0x66
#1 0xffffffff808e67ee at panic+0x1ce
#2 0xffffffff80bd39c0 at trap_fatal+0x290
#3 0xffffffff80bd3cfd at trap_pfault+0x1ed
#4 0xffffffff80bd431e at trap+0x3ce
#5 0xffffffff80bbef1f at calltrap+0x8
#6 0xffffffff80c637e4 at VOP_REMOVE_APV+0x34
#7 0xffffffff8098300d at kern_unlinkat+0x32d
#8 0xffffffff80bd3270 at amd64_syscall+0x590
#9 0xffffffff80bbf207 at Xfast_syscall+0xf7
Uptime: 4m50s
>How-To-Repeat:
Attempting to delete data using rm consistently reproduces the issue.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201207282146.q6SLkb5e094916>