From owner-freebsd-fs@FreeBSD.ORG Wed Mar 14 09:50:32 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D8751065672 for ; Wed, 14 Mar 2012 09:50:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3C08FC08 for ; Wed, 14 Mar 2012 09:50:31 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC423CA.dip.t-dialin.net [79.196.35.202]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id B1BA68446F8; Wed, 14 Mar 2012 10:50:17 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 0230C2399; Wed, 14 Mar 2012 10:50:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1331718615; bh=aOCZ8V2P6t6P16xduDNdXM+4OUqEQevEiBHYO4vf8Eg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=yCClkPFv1X0zlNbsN0o/ukU257/QCbdRhHm5YmLJ3Eq5icaW8VOyUGGFocAWvVFmn ig8V6EGZE7B3D+bzkH397glg/wUoxaSke1S8QxiepCm0W1yDW2Nj5JJoeD1Tk/k3pT 4rNE2R/CuTmc64kDYT8J1WKWRoq6d7RwAOz9iFl39OdwK6xc0CX8x6bpn4inwiImWI BYJc43OJUPEyENBvfLSl/vROXh9iyMr1F4EkzBpd5UyJe+k6TuPhaUrxvNhutiLuNg +vY0/raDEETxLwRAd/wf4QSBR977jCBRKcNJSIo6GpIv8btoOP3nRSyrvC/Wu8l7b5 kdU+dst2XK+yA== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q2E9oEs6017378; Wed, 14 Mar 2012 10:50:14 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.20 ([85.94.224.20]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 14 Mar 2012 10:50:14 +0100 Date: Wed, 14 Mar 2012 10:50:11 +0100 Message-ID: <20120314105011.Horde.mYG5YpjmRSRPYGnT6OFEHuA@webmail.leidinger.net> From: Alexander Leidinger To: Mark Murawski References: <4F5F7116.3020400@intellasoft.net> <4F5F97A4.6070000@brockmann-consult.de> <4F60266D.1090302@intellasoft.net> <4F6027B3.5080006@intellasoft.net> In-Reply-To: <4F6027B3.5080006@intellasoft.net> User-Agent: Internet Messaging Program (IMP) H4 (5.0.19) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: B1BA68446F8.A1FC2 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.385, required 6, autolearn=disabled, AWL -1.72, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_84 0.60, RCVD_IN_SORBS 1.00, RCVD_IN_SORBS_WEB 0.61, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1332323419.65587@Ej7PyRuKocxzBE1yoQI8nw X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org Subject: Re: ZFS file corruption problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:50:32 -0000 Quoting Mark Murawski (from Wed, 14 Mar 2012 01:08:03 -0400): > On 03/14/12 01:02, Mark Murawski wrote: >> Why would the whole pool now become available upon access to a bad file? Because you configured it like this (respectively didn't configure a different behavior). > Also... isn't this pretty terrible behavior that the process > accessing the bad file is unkillable? If you are in an environment where the disks are not local (ZFS is designed with corporate environments in mind), you do not want to fail on an application level or panic because of a small hickup in the network. man zpool: ---snip--- failmode=wait | continue | panic Controls the system behavior in the event of catastrophic pool fail? ure. This condition is typically a result of a loss of connectivity to the underlying storage device(s) or a failure of all devices within the pool. The behavior of such an event is determined as fol? lows: wait Blocks all I/O access until the device connectivity is recov? ered and the errors are cleared. This is the default behav? ior. continue Returns EIO to any new write I/O requests but allows reads to any of the remaining healthy devices. Any write requests that have yet to be committed to disk would be blocked. panic Prints out a message to the console and generates a system crash dump. ---snip--- It is up to you to switch to 'continue' or 'panic' for local disks. Bye, Alexander. -- In Seattle, Washington, it is illegal to carry a concealed weapon that is over six feet in length. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137