From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 17:00:29 2010 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 CE0DC106568D for ; Tue, 26 Jan 2010 17:00:29 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 5BEA38FC1D for ; Tue, 26 Jan 2010 17:00:29 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0QH0Q5f027850; Tue, 26 Jan 2010 18:00:27 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 1209C24; Tue, 26 Jan 2010 18:00:26 +0100 (CET) Date: Tue, 26 Jan 2010 18:00:25 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100126180025.83022d17.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100126164619.GA50461@icarus.home.lan> References: <20100126143021.GA47535@icarus.home.lan> <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> <20100126164619.GA50461@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.165121 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS "zpool replace" problems 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: Tue, 26 Jan 2010 17:00:29 -0000 On Tue, 26 Jan 2010 08:46:19 -0800 Jeremy Chadwick wrote about Re: ZFS "zpool replace" problems: JC> - zpool offline JC> - atacontrol detach ataX (where X = channel associated with disk) JC> - Physically remove bad disk JC> - Physically insert new disk JC> - Wait 15 seconds for stuff to settle JC> - atacontrol attach ataX (where X = previous channel detached) JC> - zpool replace JC> - zpool online JC> "reinit" shouldn't be needed at all -- in fact, I've seen reinit cause JC> some craziness (even on Intel controllers), including a system JC> deadlock, but this was back during the RELENG_6 and RELENG_7 days. JC> Great improvements have been made to ata(4) since then. Thanks for pointing that out. I would have went exactly this way, if I did not have the extra slots or one of the drives was actually faulty. But in this case I just wanted to replace every drive on-by-one and (at least I thought) I had extra slots, so I did not want to give up the redundancy during the replacement (knowing very well that the drives to be replaced are already beyond the specification of wd due to the load-cycle bug). JC> If you need me to validate the above procedure (it's been a while since JC> I've had to hot-swap a disk), I can do so. I do have a 4-disk JC> Supermicro SuperServer 5015B-MTB (ICH9-based) sitting on my workbench JC> which I can test with. I'm quite sure this will work fine. I just don't know how to get rid of the degraded replacement zfs sees. JC> It honestly sounds like hot-swapping is causing some chaos on your JC> system. Are all of the controllers involved configured for AHCI? I think so. How could I verify this? cu Gerrit