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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207464 --- 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 creating 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 without resorting to the backups. The panic is usually (but not always) preceded by a snapshot that is present, 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 system 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 directory but cannot be cd'd into. These three things make it possible for my backup script to, most of the time, 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. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207464-3630-0csMFhAIiJ>