From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 17:10:15 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 C25CD1065672 for ; Tue, 26 Jan 2010 17:10:15 +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 4E72F8FC0A for ; Tue, 26 Jan 2010 17:10:14 +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 o0QHACYp028394; Tue, 26 Jan 2010 18:10:13 +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 A477924; Tue, 26 Jan 2010 18:10:12 +0100 (CET) Date: Tue, 26 Jan 2010 18:10:12 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Chuck Swiger Message-Id: <20100126181012.4669d417.gerrit@pmp.uni-hannover.de> In-Reply-To: <5F20B2B6-D75C-4E27-9CC9-85C6E64D13BD@mac.com> References: <20100126143021.GA47535@icarus.home.lan> <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> <20100126172503.927e1bb5.gerrit@pmp.uni-hannover.de> <5F20B2B6-D75C-4E27-9CC9-85C6E64D13BD@mac.com> 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.170039 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:10:15 -0000 On Tue, 26 Jan 2010 08:59:27 -0800 Chuck Swiger wrote about Re: ZFS "zpool replace" problems: CS> As a general matter of maintaining RAID systems, however, the approach CS> to upgrading drive firmware on members of a RAID array should be to CS> take down the entire container and offline the drives, update one CS> drive, test it (via SMART self-test and read-only checksum comparison CS> or similar), and then proceed to update all of the drives (preferably CS> doing the SMART self-test for each, if time allows) before returning CS> them to the RAID container and onlining them. Well, I had several spare drives sitting on the shelf. So I updated the firmware of these spare drives and now want to replace the drives with the old firmware by new new ones one-by-one. Taking the system offline for longer than a few minutes is not really an option. I'd rather roll in a new machine to take over the job in that case. CS> Pulling individual drives from a RAID set while live and updating the CS> firmware one at a time is not an approach I would take-- running with CS> mixed firmware versions doesn't thrill me, and I know of multiple CS> cases where someone made a mistake reconnecting a drive with the wrong CS> SCSI id or something like that, taking out a second drive while the CS> RAID was not redundant, resulting in massive data corruption or even CS> total loss of the RAID contents. This scenario was exactly the reason why I plugged in the new drive to an extra slot and asked zfs to replace it with an old one. Well, I did not know what kind of fiasco the controller for this extra slot would turn out to be - otherwise I would have used the hot-spare slot for this in the first place. cu Gerrit