From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 18:38:01 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5979F16A4CE for ; Fri, 4 Mar 2005 18:38:01 +0000 (GMT) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 466B443D1D for ; Fri, 4 Mar 2005 18:38:00 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j24IbmYL029539 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 5 Mar 2005 05:37:50 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j24Ibm7l008040; Sat, 5 Mar 2005 05:37:48 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j24Ibl5t008039; Sat, 5 Mar 2005 05:37:47 +1100 (EST) (envelope-from pjeremy) Date: Sat, 5 Mar 2005 05:37:47 +1100 From: Peter Jeremy To: ALeine Message-ID: <20050304183747.GS57256@cirb503493.alcatel.com.au> References: <200503022115.j22LFnWk083926@marlena.vvi.at> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200503022115.j22LFnWk083926@marlena.vvi.at> User-Agent: Mutt/1.4.2i cc: phk@phk.freebsd.dk cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 18:38:01 -0000 [CC list pruned] On Wed, 2005-Mar-02 13:15:49 -0800, ALeine wrote: >If only hardware manufacturers were to equip hard drives with >a mechanism to ensure atomic writes. A capacitor large enough >to hold enough energy to flush the cache upon detecting the >power supply was cut would be sufficient. I'm not sure thus is readily practical at the drive level. Based on some back-of-envelope calculations using figures in a Seagate Barracuda manual (which I happened to have handy): - Random seek is 9.5 msec. - Rotational period is 8.3msec - Power consumption at 50% R/W, 50% seek is 0.82A @ 12V + 0.68A @ 5V A single random seek + track write will take 17.8 msec. This translates to an electrical charge of 0.015C @ 12V and 0.012C @ 5V. Assuming the drive is designed to allow the supply rails to droop 20% whilst functioning correctly during this shutdown phase (which is a significantly bigger drop than the standard specifications), a single random seek + track write would require the drive to include a 6000µF capacitor on the 12V rail and a 12000µF capacitor on the 5V rail. As a first order approximation all Unix disk operations are writes (reads can be satisfied from the buffer cache). Given the size of current generation drive caches, it's more likely that there are around 50 writes cached - which requires capacitors 50 times as large - which would make them significantly larger than the drive itself. > They could even use >a battery the status of which could be monitored via S.M.A.R.T., >I don't see how implementing something like that could possibly >make the cost noticably higher. Batteries (and standard supercaps) are generally designed to release their energy over an extended period - several minutes is the lower realistic limit. It would make sense to build a battery backup system which maintained power for (say) 5 minutes. It's not realistic to build a battery backup system that can release all it's available energy in 1 second. If you're going to the effort of building a battery backup system, you might as well backup the entire computer. These are available off the shelf and have the added advantage of allowing users and the system to clean up before the power goes away. -- Peter Jeremy