ZFS panic on mdX-based raidz

[Pawel Jakub Dawidek]

On Fri, Jun 15, 2007 at 09:00:07PM +0100, Joao Barros wrote:
> On 6/15/07, Pawel Jakub Dawidek <pjd at freebsd.org> wrote:
> >On Fri, Jun 15, 2007 at 04:57:17PM +0200, Lapo Luchini wrote:
> >> Pawel Jakub Dawidek wrote:
> >> >> Follows the status with two invalid disks (I wonder why :P) and a scrub
> >> >> in progress; but the host will panic before the scrub ends.
> >> >>
> >> >
> >> > You corrupted two components in configuration with accepts only one disk
> >> > failure.
> >> Yes, I'm well aware of that (it was intentional, in fact), and the
> >> "invalid" state of the pool was fully expected.. while the kernel panic
> >> short thereafter was a bit less so ;-)
> >> Not a very urgent or pressing issue, I do agree, I reported it mainly
> >> for completeness sake.
> >
> >But this is very expected behaviour of ZFS.
> 
> Let's suppose I have 2 raidz, one volume using disks on one enclosure
> and another volume using disks on another enclosure. One of the
> enclosures is disconnected, doesn't matter why. Is ZFS going to panic
> the machine thus rendering the other volume unavailable? From what
> I've seen the volume is marked as failed and that's what's supposed to
> happen.
> Or when you say intentional was just for md backed devices?

When ZFS cannot write data and there is not enough redundancy it will
panic. Sun is working on this AFAIK.

Write failure is not easy to handle, because most writes are delayed, so
we can't return an error back to application. It shouldn't panic entire
system still, but eventually unmount it forcibly.

ZFS can survive write failure of one component in two-way mirror or
raidz1 configuration or two components in raidz2 configuration. It can
also survive write failure in non-redundant configuration when copies
property is greater than 1 and we can write at least one copy
successfully.

Two cases on the other hand should be handled better (now they panic the
system):

1. Write fails, because of more number of components is missing that we
can accept in our configuration. It should most likely forcibly unmount
the file system (file systems?).

2. Write fails, because of bad block. ZFS should just try to write in
another location and doesn't do it now. This should be quite easy to
implement because of COW model, but it's not there yet.

Anyway, be aware of those limitation when you decide to abuse it too
much next time:)

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070616/d8712383/attachment.pgp