Date: Fri, 4 Mar 2005 14:06:06 -0500 From: Brian Fundakowski Feldman <green@freebsd.org> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE Message-ID: <20050304190606.GF6011@green.homeunix.org> In-Reply-To: <20050304183747.GS57256@cirb503493.alcatel.com.au> References: <200503022115.j22LFnWk083926@marlena.vvi.at> <20050304183747.GS57256@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 05, 2005 at 05:37:47AM +1100, Peter Jeremy wrote: > [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. This is not what anyone is asking to achieve. What is being asked is not to lose a whole track just because one sector on the track was being written upon power loss. Dealing with many in-order writes being lost (in order), upon power loss, is something the filesystems are already written to assume, and the fsync(2) semantics are designed to work with. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050304190606.GF6011>