From owner-freebsd-fs@FreeBSD.ORG Sun Apr 6 11:20:56 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D332D14F for ; Sun, 6 Apr 2014 11:20:56 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67DFB33A for ; Sun, 6 Apr 2014 11:20:56 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so3527686wiv.15 for ; Sun, 06 Apr 2014 04:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8DGfzr8lIWLF0xhCmO7J1E7N1xaK6EqJNHrusRYp7Qs=; b=JKYEzLkx4eaLt5aLtfXhEp+FsHdbkzDYjuJdg2/lDxqPHAxtoPz4Az2UovaF1RR7Ms +VgQa/BlzokkbgAfhuYvK4R3xa4VSrkd4TxWoxsRvrXvRnAm+M7sB8rnCd8RcsNIVbUn 8gKHLj6dxdTN+TfiHP6BXjyq37spXDqAlZFq5nSwch9/93h4+6QGRT5AVnQOU8sdFgJ/ wSGG4HoCZ7wdnWTBwDHIpDRpGE5eaxmI6eS2//vd5+aHAHHRwdbT0/4K4uRasEdX3log e2Se+/clzK0i68beFiMlNVU/Vrv2WCn6NN8wR80d9neyOwzMa0F88E+QxyzIAA4ub54n T8og== X-Received: by 10.180.12.14 with SMTP id u14mr18489882wib.0.1396783254642; Sun, 06 Apr 2014 04:20:54 -0700 (PDT) Received: from [192.168.20.30] (81-178-2-118.dsl.pipex.com. [81.178.2.118]) by mx.google.com with ESMTPSA id ll1sm21279311wjc.6.2014.04.06.04.20.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Apr 2014 04:20:53 -0700 (PDT) Message-ID: <53413894.4050400@gmail.com> Date: Sun, 06 Apr 2014 12:20:52 +0100 From: Kaya Saman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Device Removed by Administrator in ZPOOL? References: <53408FAB.8080202@gmail.com> <512A7865-CEFD-4BDA-A060-AE911BEDD5B7@tuxsystems.co.za> <53409BF1.6050001@gmail.com> <20140406002849.GA14765@neutralgood.org> <5340B1C5.4000700@gmail.com> <5340E0EE.8010905@denninger.net> In-Reply-To: <5340E0EE.8010905@denninger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 11:20:56 -0000 On 04/06/2014 06:06 AM, Karl Denninger wrote: > > On 4/5/2014 8:45 PM, Kaya Saman wrote: >> On 04/06/2014 01:28 AM, kpneal@pobox.com wrote: >>> On Sun, Apr 06, 2014 at 01:12:33AM +0100, Kaya Saman wrote: >>>> Many thanks for the response! >>>> >>>> The server doesn't show any lights for "drive error" however, the blue >>>> read LED isn't coming on, on the drive in question (as removed from >>>> ZPOOL). >>>> >>>> I will have a look for LSI tools in @Ports and also see if the BIOS >>>> LSI >>>> hook comes up with anything. >>> Have you seen any other errors in your logs? Seems like if a drive >>> fails >>> there should be some other error message reporting the errors that >>> resulted >>> in ZFS marking the drive removed. What does 'dmesg' have to say? >>> >>> Once ZFS has stopped using the drive (for whatever reason) I wouldn't >>> expect you to see anything else happening on the drive. So the light >>> not >>> coming on doesn't really tell us anything new. >>> >>> Also, aren't 'green' drives the kind that spin down and then have to >>> spin >>> back up when a request comes in? I don't know what happens if a >>> drive takes >>> "too long" to respond because it has spun down. I have no idea how >>> FreeBSD >>> handles that, and I also don't know if ZFS adds anything to the >>> equation. >>> Hopefully someone else here will clue me/us in. >> >> Ok this is really weird.... just did a reboot and now: >> >> $ zpool status >> pool: ZPOOL_2 >> state: ONLINE >> status: One or more devices is currently being resilvered. The pool >> will >> continue to function, possibly in a degraded state. >> action: Wait for the resilver to complete. >> scan: resilver in progress since Sun Apr 6 02:43:03 2014 >> 1.13G scanned out of 7.77T at 22.2M/s, 101h57m to go >> 227M resilvered, 0.01% done >> config: >> >> NAME STATE READ WRITE CKSUM >> ZPOOL_2 ONLINE 0 0 0 >> raidz2-0 ONLINE 0 0 0 >> da0 ONLINE 0 0 0 >> da1 ONLINE 0 0 0 (resilvering) >> da2 ONLINE 0 0 0 >> da3 ONLINE 0 0 0 >> da4 ONLINE 0 0 0 >> >> >> ???? Looks like the drive might have fallen off the controller? >> >> Am just looking at the tools for it on the LSI website but there >> doesn't seem to be anything FreeBSD related.... Linux and Solaris yes >> but no FBSD? >> >> Model is LSI SAS 9207-4i4e >> > It looks like the drive detached itself. I've seen those "Green" > drives do this before; they go to "sleep" if quiescent, and sometimes > fail to wake up properly. The controller then detaches them thinking > they're dead, but they're not... > > I'd get those things off your system. They work ok for desktop PCs > but I don't like them in servers. > Thanks for the info..... I didn't want to go for the "Green" variant either but they seemed to be highest in capacity for 2.5" drives which is why I really had no choice. I prefer WD Black drives as I've had really good experiences with them. Guess I'll just have to wait till the capacity of the smaller drives increases :-( Regards, Kaya