From owner-freebsd-stable@FreeBSD.ORG Sun Dec 30 23:38:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3181F5C for ; Sun, 30 Dec 2012 23:38:48 +0000 (UTC) (envelope-from greg.bonett@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 799AA8FC0C for ; Sun, 30 Dec 2012 23:38:48 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so12466914vcb.27 for ; Sun, 30 Dec 2012 15:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+zTWcnrSY7HKoG4U5k55foqzEjvdIFD6uq7qJIT5ojM=; b=kJcm6Uocw2XGI8sPHlnp9jebNQFJBPti+sG6QhJroQuexZbHeBIf7WHXF1opma0HhC dtwCNuPc6GpNAojl4o1SICcQwcGbqlQcIGRI9jzBuIAyWDEXDowCZNYfgzRO6JvqCpbB s/b+ZtRP9s4C3+wAojv2paMpIk51fMiG9dGap7VY6bSK0vM8IpySyZp8agHxm2arBM3n BQ1fAi0l0hSrCxYQgeVz8wrgIoDIzFE31D2hlGnIZ5RxmzeKYh1vyRrOfWfdmhcjfhmm sIri8fN7Yy2fT0rUMt1fUqagHU81d2T+h2g6wmfKUxYT+sYQDgS9gsjzfuw1K9E/G4qT 4C2g== MIME-Version: 1.0 Received: by 10.58.222.40 with SMTP id qj8mr63405317vec.36.1356910721228; Sun, 30 Dec 2012 15:38:41 -0800 (PST) Received: by 10.58.40.33 with HTTP; Sun, 30 Dec 2012 15:38:41 -0800 (PST) In-Reply-To: <20121230123213.2312fb47@fabiankeil.de> References: <20121230123213.2312fb47@fabiankeil.de> Date: Sun, 30 Dec 2012 15:38:41 -0800 Message-ID: Subject: Re: how to destroy zfs parent filesystem without destroying children - corrupted file causing kernel panick From: Greg Bonett To: Fabian Keil Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 23:38:48 -0000 > > My next plan would be reporting the problem with sufficient > information so the bug can be fixed. > > Destroying the dataset or the whole pool seems like papering over the > real issue to me and you could still do it if the PR gets ignored for > too long or a developer agrees that this is the only option. > > ok, that's a good idea - do you know where I should report this problem? unfortunately, I don't know how I can provide the problematic file because any read, cp, or mv causes kernel panic.