Date: Thu, 05 May 2016 18:24:18 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 207464] Panic when destroying ZFS snapshot on boot filesystem Message-ID: <bug-207464-3630-0csMFhAIiJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-207464-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-207464-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207464 --- Comment #14 from karl@denninger.net --- Andy, is that WITH the one-line patch in? If so, bummer. The pattern for me here on my production machines is that during backup the machine will panic, *always* during the root filesystem backup. The system is all-ZFS and the backups are done using zfs send, after creati= ng a snapshot (which rolls so you wind up with a duplicate of the existing file structure over time.) The system also uses timed snapshots that roll off so recovery of files is simple if they're accidentally deleted or modified wit= hout resorting to the backups. The panic is usually (but not always) preceded by a snapshot that is presen= t, cannot be destroyed, but *also* cannot be CD'd into. Once that condition exists the following is also true: 1. If you *reboot* the box the condition is cleared and all is well; the sy= stem will *not* panic in that instance. 2. If you attempt to zfs send a stream that *includes* the "orphan" snapshot the machine will panic in dounmount (identical behavior to the traces posted here) every time. 3. You cannot zfs destroy the "rogue" snapshot that is present in the direc= tory but cannot be cd'd into. These three things make it possible for my backup script to, most of the ti= me, detect the panic condition on the backup run *before* the one that blows up. What I've been unable to do, however, is reproduce a test case that reliably leaves the system in the pre-panic state. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207464-3630-0csMFhAIiJ>