From owner-freebsd-fs@FreeBSD.ORG Wed May 19 17:59:55 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BBF6106566B for ; Wed, 19 May 2010 17:59:55 +0000 (UTC) (envelope-from tsw5@duke.edu) Received: from smtp.duke.edu (smtp-03.oit.duke.edu [152.3.174.16]) by mx1.freebsd.org (Postfix) with ESMTP id 11EE58FC0A for ; Wed, 19 May 2010 17:59:54 +0000 (UTC) Received: from smtp.duke.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1752E8204; Wed, 19 May 2010 13:59:54 -0400 (EDT) Received: from [152.3.137.189] (k.cs.duke.edu [152.3.137.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.duke.edu (Postfix) with ESMTP id F213E8052; Wed, 19 May 2010 13:59:53 -0400 (EDT) Message-ID: <4BF4272A.9020204@duke.edu> Date: Wed, 19 May 2010 14:00:10 -0400 From: Todd Wasson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Wes Morgan References: <0B97967D-1057-4414-BBD4-4F1AA2659A5D@duke.edu> <4BF0F231.9000706@mapper.nl> <53F15A8B-77DA-4CEF-A790-2902BEC91002@duke.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2010.5.19.174815 Cc: freebsd-fs@freebsd.org Subject: Re: zfs drive replacement issues X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 17:59:55 -0000 > I'm not certain that you really always want to do that. When you offline a > device in a redundant pool you lose that redundancy. If you have a drive > that is completely dead, it is obviously the right thing to do, but > otherwise perhaps not. Were you the have another failure during the > rebuild, or if there was another error on a different vdev, you wouldn't > be able to recover that data because of the missing device. The same > reason why offlining and replacing each device in a raidz1 to "grow" it > isn't as safe as you might think -- any error could lead to data loss. > > Just food for thought. I'm guessing the implication here is that it's better to connect the new drive in addition to the old one, then, like via USB or eSATA interface? In a machine with no extra interfaces, as was the case for me, offlining it seemed to be the only choice. Maybe it's just time to invest in a USB SATA cable, just in case... Thanks! Todd