From owner-freebsd-stable@FreeBSD.ORG Thu Feb 15 09:35:42 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81D9116A401 for ; Thu, 15 Feb 2007 09:35:42 +0000 (UTC) (envelope-from harry@schmalzbauer.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id D929E13C467 for ; Thu, 15 Feb 2007 09:35:41 +0000 (UTC) (envelope-from harry@schmalzbauer.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l1F9ZY7R011719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2007 10:35:39 +0100 (CET) (envelope-from harry@schmalzbauer.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.49]) by tek.flintsbach.schmalzbauer.de (8.13.6/8.13.6) with ESMTP id l1F9ZY3D060930; Thu, 15 Feb 2007 10:35:34 +0100 (CET) (envelope-from harry@schmalzbauer.de) Received: from localhost (localhost [[UNIX: localhost]]) by titan.flintsbach.schmalzbauer.de (8.13.8/8.13.8/Submit) id l1F9ZXS6002245; Thu, 15 Feb 2007 10:35:33 +0100 (CET) (envelope-from harry@schmalzbauer.de) X-Authentication-Warning: titan.flintsbach.schmalzbauer.de: harry set sender to harry@schmalzbauer.de using -f From: Harald Schmalzbauer To: freebsd-stable@freebsd.org Date: Thu, 15 Feb 2007 10:35:33 +0100 User-Agent: KMail/1.9.4 References: <200701300854.l0U8sh4f005370@lurza.secnetix.de> In-Reply-To: <200701300854.l0U8sh4f005370@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702151035.33807.harry@schmalzbauer.de> Cc: Oliver Fromme Subject: Re: gmirror or ata problem 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, 15 Feb 2007 09:35:42 -0000 Am Dienstag, 30. Januar 2007 09:54 schrieb Oliver Fromme: > Hi, > > This is strange. gmirror just detached one of its disks > for no apparent reason. I've built a mirror consisting of > the components ad0 and ad1 (both SATA drives). It has > been running fine. This is RELENG_6 from 2006-12-20. > > Yesterday evening ad1 was detached. There is no other > error message logged on console or in the logs (i.e. no > I/O error such as a bad sector or anything). There was > no particularly high load at that time. In fact, the > machine had been under much higher load before, without > anything bad happening. > > This is from the logs: > > Jan 29 19:10:13 pluto -- MARK -- > Jan 29 19:20:26 pluto kernel: ad1: FAILURE - device detached > Jan 29 19:20:26 pluto kernel: subdisk1: detached > Jan 29 19:20:26 pluto kernel: ad1: detached > Jan 29 19:20:26 pluto kernel: GEOM_MIRROR: Cannot write metadata on ad1 > (device=gm0, error=6). Jan 29 19:20:26 pluto kernel: GEOM_MIRROR: Cannot > update metadata on disk ad1 (error=6). Jan 29 19:20:26 pluto kernel: > GEOM_MIRROR: Cannot update metadata on disk ad1 (error=6). Jan 29 19:20:26 > pluto kernel: GEOM_MIRROR: Device gm0: provider ad1 disconnected. Jan 29 > 19:50:13 pluto -- MARK -- > > This almost looks like typical Windows problems: Something > reports a "failure", but no reason or any other useful > information. :-( > > "atacontrol list" reports for ad1:: > > Master: no device present > > After an atacontrol detach/attach cycle, the device is back > again: > > Master: ad1 Serial ATA II > > I inserted it back into the gmirror, and right now it's > synchronizing happily. > > Can anybody please explain what happened, and -- more > importantly -- how to avoid it in the future? As far as > I can tell, the disk drives are perfectly OK. I think this is a problem when the internal thermal recalibration takes too long. Consumer HDDs can be "offline" quiet some time, I don't have numbers handy, but see Western Digitals explanation on their SATA RE (RaidEdition) Drives. Again, no link handy, sorry. -Harry