From owner-freebsd-stable@FreeBSD.ORG Thu Jul 23 18:57:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2272C1065672 for ; Thu, 23 Jul 2009 18:57:38 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id E9E1B8FC12 for ; Thu, 23 Jul 2009 18:57:37 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 9CD653BD017 for ; Thu, 23 Jul 2009 14:57:37 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 23 Jul 2009 14:57:37 -0400 X-Sasl-enc: lK5Dq2eDvWaImM3PMhhkVY9R2+JY/UOpieMsYsyd/aCD 1248375457 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 46AF9B61E for ; Thu, 23 Jul 2009 14:57:37 -0400 (EDT) Message-ID: <4A68B2A0.8050509@incunabulum.net> Date: Thu, 23 Jul 2009 19:57:36 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <200901232244.n0NMiRmM098646@lurza.secnetix.de> <46acbb3e-71bc-4cff-93d7-59b48a1a9302@exchange01.ecp.noc> In-Reply-To: <46acbb3e-71bc-4cff-93d7-59b48a1a9302@exchange01.ecp.noc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ataraid's revenge! (Was: Re: A nasty ataraid experience.) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:57:38 -0000 6 months on, ataraid(4) did it again. This time, I was lucky -- I caught in in time, but the damage to the filesystem meant having to use fsdb to NULL out the affected inodes; mounting read-only, tarring, and untarring across the network, after a newfs, let me save the affected partition. All I was doing at the time was srm'ing a few sensitive files; all the processes wedged in WCHAN getblk. It seems ataraid(4) is not robust against temporary drive/controller problems. The SMART logs on the affected array drives all check out just fine, there are no bad block remaps. So, time to either buy a hardware RAID controller, or move to ZFS...