From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 13:55:08 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 43AC9106566B for ; Mon, 8 Feb 2010 13:55:08 +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 C5E978FC12 for ; Mon, 8 Feb 2010 13:55:07 +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 o18Dt4CV021090; Mon, 8 Feb 2010 14:55:06 +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 E54C624; Mon, 8 Feb 2010 14:55:04 +0100 (CET) Date: Mon, 8 Feb 2010 14:55:04 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Dan Naumov Message-Id: <20100208145504.762eaa7b.gerrit@pmp.uni-hannover.de> In-Reply-To: References: 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.2.8.133622 Cc: FreeBSD-STABLE Mailing List Subject: Re: one more load-cycle-count 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: Mon, 08 Feb 2010 13:55:08 -0000 On Mon, 8 Feb 2010 15:43:46 +0200 Dan Naumov wrote about RE: one more load-cycle-count problem: DN> >Any further ideas how to get rid of this "feature"? DN> 1) The most "clean" solution is probably using the WDIDLE3 utility on DN> your drives to disable automatic parking or in cases where its not DN> possible to complete disable it, you can adjust it to 5 minutes, which DN> essentially solves the problem. Note that going this route will DN> probably involve rebuilding your entire array from scratch, because DN> applying WDIDLE3 to the disk is likely to very slightly affect disk DN> geometry, but just enough for hardware raid or ZFS or whatever to bark DN> at you and refuse to continue using the drive in an existing pool (the DN> affected disk can become very slightly smaller in capacity). Backup DN> data, apply WDIDLE3 to all disks. Recreate the pool, restore backups. DN> This will also void your warranty if used on the new WD drives, DN> although it will still work just fine. Thanks for the warning. How on earth can a tool to set the idle time affect the disk geometry?! DN> 2) A less clean solution would be to setup a script that polls the DN> SMART data of all disks affected by the problem every 8-9 seconds and DN> have this script launch on boot. This will keep the affected drives DN> just busy enough to not park their heads. That's what I'm doing since yesterday when I first noted the problem on this particular system. Not a pretty solution either. I'm close of buying Hitachi drives instead (HTE545050B9A300). Does anyone here know these drives and can confirm that they do not have this kind of problem (I would expect it because of the 24/7 certification)? cu Gerrit