From sommerfeld@sun.com Mon May 21 12:17:22 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4LJHM6d006994 for ; Mon, 21 May 2007 12:17:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4LJFwOu010343; Mon, 21 May 2007 13:16:01 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIE0060LO6X9000@nwk-avmta-1.sfbay.Sun.COM>; Mon, 21 May 2007 12:16:09 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIE0024MO6WJ470@nwk-avmta-1.sfbay.Sun.COM>; Mon, 21 May 2007 12:16:08 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4LJG7tN002755; Mon, 21 May 2007 15:16:07 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4LJG7xJ008363; Mon, 21 May 2007 15:16:07 -0400 (EDT) Date: Mon, 21 May 2007 15:16:06 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2007/283 FMA for ZFS Phase 2 In-reply-to: <200705211640.l4LGeKM8001966@zion.eng.sun.com> To: Michael Shapiro Cc: psarc-ext@sun.com, eric.schrock@sun.com, mws@sun.com Message-id: <1179774966.7156.20.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705211640.l4LGeKM8001966@zion.eng.sun.com> Status: RO Content-Length: 1030 On Mon, 2007-05-21 at 09:40 -0700, Michael Shapiro wrote: > If any ARC members > have questions or believe the case is above the automatic approval > threshold, please let us know. I reviewed the portfolio and have a couple questions about section 6.4 of http://fma.eng/documents/engineering/portfolios/2007/006.ZFS-P2/portfolio.txt As this is an open case it would help if you made these documents part of the public record of the case or otherwise provide a internet-accessible URL to them. Secondly: For I/O faults (fault.fs.zfs.vdev.io), the device will be offlined and marked FAULTED in the pool configuration. This information will be persistently recorded on disk to eliminate the window between pool open and fmd fault replay. The materials are somewhat vague about the SERD engine parameters and the nature of what qualifies for an "I/O" error. Is there any provision for automatic recovery in the event that I/O errors were due to a transient loss of connectivity between the host and storage? From eschrock@zion.eng.sun.com Mon May 21 13:08:20 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4LK8KTk007998 for ; Mon, 21 May 2007 13:08:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4LK6w7R028305; Mon, 21 May 2007 21:07:06 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIE00J07QJQLP00@nwk-avmta-2.sfbay.sun.com>; Mon, 21 May 2007 13:07:02 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIE00BTZQJP2A90@nwk-avmta-2.sfbay.sun.com>; Mon, 21 May 2007 13:07:01 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4LK71lw015883; Mon, 21 May 2007 13:07:01 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l4LK70GW008598; Mon, 21 May 2007 13:07:00 -0700 (PDT) Received: (from eschrock@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id l4LK70Fs008597; Mon, 21 May 2007 13:07:00 -0700 (PDT) Date: Mon, 21 May 2007 13:07:00 -0700 From: Eric Schrock Subject: Re: PSARC 2007/283 FMA for ZFS Phase 2 In-reply-to: <1179774966.7156.20.camel@thunk> To: Bill Sommerfeld Cc: Michael Shapiro , psarc-ext@sun.com, mws@sun.com Message-id: <20070521200659.GA8298@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200705211640.l4LGeKM8001966@zion.eng.sun.com> <1179774966.7156.20.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1660 On Mon, May 21, 2007 at 03:16:06PM -0400, Bill Sommerfeld wrote: > > As this is an open case it would help if you made these documents part > of the public record of the case or otherwise provide a > internet-accessible URL to them. Sure thing. Presumably putting them in the materials for the case accomplishes this? > Secondly: > > For I/O faults (fault.fs.zfs.vdev.io), the device will be > offlined and marked FAULTED in the pool configuration. This > information will be persistently recorded on disk to eliminate > the window between pool open and fmd fault replay. > > The materials are somewhat vague about the SERD engine parameters and > the nature of what qualifies for an "I/O" error. Is there any provision > for automatic recovery in the event that I/O errors were due to a > transient loss of connectivity between the host and storage? The SERD engine parameters are an implementation detail. At the moment we are working with PAE and their RAS data to determine reasonable values for the first pass. An I/O error is anything for which ldi_strategy() fails twice (once with B_FAILFAST and once without), though this is an implementation detail of ZFS and may change in the future. The SERD values will try to take into account transient failure. The FMA design allows for these values to be easily changed via the .conf file and adapted as we learn more about this method of diagnosis. There is no provision for automatic recovery, as this would require some fundamental changes to the FMA model that are beyond the scope of this case. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock