Re: ZFS kernel panic

On Tuesday 28 August 2007, Bakul Shah wrote:
> > > 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).

This is complete nonsense!  As you pointed out earlier zfs doesn't know 
anything about the nature of the error.  There is only one sensible way 
to deal with a disk error - unless it is transient - and that is stopping 
all (write) access to the drive.  As you can't easily move a mounted 
drive with opened files into read-only mode, a panic is the only way to 
make sure.

> 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.

-- 
/"\  Best regards,                      | mlaier_at_freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier_at_EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News