From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:23:00 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 6D59E1065670 for ; Mon, 8 Feb 2010 14:23:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 547728FC15 for ; Mon, 8 Feb 2010 14:23:00 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta07.emeryville.ca.mail.comcast.net with comcast id fS3b1d0031smiN4A7SP03c; Mon, 08 Feb 2010 14:23:00 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id fSP01d0083S48mS8gSP0Ve; Mon, 08 Feb 2010 14:23:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 174B11E3033; Mon, 8 Feb 2010 06:22:59 -0800 (PST) Date: Mon, 8 Feb 2010 06:22:59 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100208142259.GA3210@icarus.home.lan> References: <20100208145504.762eaa7b.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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 14:23:00 -0000 On Mon, Feb 08, 2010 at 03:56:35PM +0200, Dan Naumov wrote: > 2010/2/8 Gerrit Kühn : > > 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?! > > WDIDLE3 changes the drive firmware. This is also how WD can detect > you've used it on your disk and void your warranty accordingly :) I have to assume WDIDLE3 is identical in implementation/style as WDTLER is -- the firmware itself does not change but rather some tuning settings in an EEPROM on the drive PCB (which may be embedded in the on-PCB I/O controller -- yes this is possible, PIC chips offer this). Last I remember, there *is not* a way to determine if someone has ever adjusted these settings. As long as you set them back to their factory defaults (whatever those values are; the EXEs tell you what they were before they change them), there's no accurate way to determine whether or not the settings had been adjusted since the disk was shipped. The DOS utilities submit custom ATA CMDs or data to all WD disks to toggle or adjust these features. If someone could figure out what the command(s) were, the feature(s) could be implemented into atacontrol(8). Of course, that would require reverse-engineering of the EXEs, which would probably induce DMCA-related lawsuits (in the US). Sad too, since documentation of said feature(s) would improve customer satisfaction. But hey, I'm just an engineer, what do I know. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |