From owner-freebsd-current@FreeBSD.ORG  Tue Aug 28 21:14:40 2007
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D089916A419;
	Tue, 28 Aug 2007 21:14:40 +0000 (UTC)
	(envelope-from bakul@bitblocks.com)
Received: from mail.bitblocks.com (ns1.bitblocks.com [64.142.15.60])
	by mx1.freebsd.org (Postfix) with ESMTP id B04D413C4B6;
	Tue, 28 Aug 2007 21:14:40 +0000 (UTC)
	(envelope-from bakul@bitblocks.com)
Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1])
	by mail.bitblocks.com (Postfix) with ESMTP id 470805B3B;
	Tue, 28 Aug 2007 14:14:40 -0700 (PDT)
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
In-reply-to: Your message of "Tue, 28 Aug 2007 22:55:55 +0200."
	<20070828205554.GI39562@garage.freebsd.pl> 
Date: Tue, 28 Aug 2007 14:14:40 -0700
From: Bakul Shah <bakul@bitblocks.com>
Message-Id: <20070828211440.470805B3B@mail.bitblocks.com>
Cc: current@FreeBSD.org, Pascal Hofstee <caelian@gmail.com>
Subject: Re: ZFS kernel panic 
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Aug 2007 21:14:40 -0000

> > The simplest thing to do in case of a write error is to
> > simply ignore it.  You *will* catch this problem when you try
> > to read this block.  One step better is to do what you
> > suggest.
> 
> You can't ignore write error, because application already assumed the
> write succeeded, which can lead to misbehaviour later. ZFS cannot yet
> handle write error, so it panics to preserve data consistency. This is
> the good reaction on ZFS side until skipping bad blocks is not
> implemented.

If you ignore a write error, the effect is the same as if the
disk block was good on writing but went bad before the first
read.  Seems to me this is better than panicing (but of
course not as good as finding an alternate block).

AFAIK ZFS already uses redundancy for metadata so the
metadata consistency will be maintained.

> > What happens now when you do use redundancy and there is a
> > write error while writing one of the copies?  Does the system
> > panic or is this error ignored?
> 
> Don't remember off hand, but component is probably marked as bad and
> vdev group goes to degraded state. You can simulate this easly with
> gnop(8).

Thanks.  It would be good to add some ioctl to allow failing
specific blocks on reads and/or writes.