LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Bryan Henderson <hbryan@us.ibm.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Al Boldi <a1426z@gawab.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
David Chinner <dgc@sgi.com>,
linux-kernel@vger.kernel.org, Pavel Machek <pavel@ucw.cz>,
Daniel Phillips <phillips@google.com>,
ric@emc.com, Rik van Riel <riel@redhat.com>,
Theodore Tso <tytso@mit.edu>,
Valerie Henson <val.henson@gmail.com>
Subject: Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck)
Date: Fri, 18 Jan 2008 14:35:55 -0800 [thread overview]
Message-ID: <OFDAE81670.76D5065A-ON882573D4.007A239B-882573D4.007C23CE@us.ibm.com> (raw)
In-Reply-To: <47910D6E.3070801@garzik.org>
I just had a talk with a colleague, John Palmer, who worked on disk drive
design for about 5 years in the '90s and he gave me a very confident,
credible explanation of some of the things we've been wondering about disk
drive power loss in this thread, complete with demonstrations of various
generations of disk drives, dismantled.
First of all, it is plain to see that there is no spring capable of
parking the head, and there is no capacitor that looks big enough to
possibly supply the energy to park the head, in any of the models I looked
at. Since parking of the heads is essential, we can only conclude that
the myth of the kinetic energy of the disks being used for that (turned
into electricity by the drive motor) is true. The energy required is not
just to move the heads to the parking zone, but to latch them there as
well.
The myth is probably just that that energy is used for anything else; it's
really easy to build a dumb circuit to park the heads using that power;
keeping a computer running is something else.
The drive does drop a write in the middle of the sector if it is writing
at the time of power loss. The designers were too conservative to keep
writing as power fails -- there's no telling what damage you might do. So
the drive cuts the power to the heads at the first sign of power loss. If
a write was in progress, this means there is one garbage sector on the
disk. It can't be read.
Trying to finish writing the sector is something I can image some drive
model somewhere trying to do, but if even _some_ take the conservative
approach, everyone has to design for it, so it doesn't matter.
A device might then reassign that sector the next time you try to write to
it (after failing to read it), thinking the medium must be bad. But there
are various algorithms for deciding when to reassign a sector, so it might
not too.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
next prev parent reply other threads:[~2008-01-18 22:36 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 21:22 [RFD] Incremental fsck Al Boldi
2008-01-08 21:31 ` Alan
2008-01-09 9:16 ` Andreas Dilger
2008-01-12 23:55 ` Daniel Phillips
2008-01-08 21:41 ` Rik van Riel
2008-01-09 4:40 ` Al Boldi
2008-01-09 7:45 ` Valerie Henson
2008-01-09 11:52 ` Al Boldi
2008-01-09 14:44 ` Rik van Riel
2008-01-10 13:26 ` Al Boldi
2008-01-12 14:51 ` Theodore Tso
2008-01-13 11:05 ` Al Boldi
2008-01-13 17:19 ` Pavel Machek
2008-01-13 17:41 ` Alan Cox
2008-01-15 20:16 ` [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck) Pavel Machek
2008-01-15 21:43 ` David Chinner
2008-01-15 23:07 ` Pavel Machek
2008-01-15 23:44 ` Daniel Phillips
2008-01-16 0:15 ` Alan Cox
2008-01-16 1:24 ` Daniel Phillips
2008-01-16 1:36 ` Chris Mason
2008-01-17 20:54 ` Pavel Machek
2008-01-16 19:06 ` Bryan Henderson
2008-01-16 20:05 ` Alan Cox
2008-01-17 2:02 ` Daniel Phillips
2008-01-17 21:37 ` Bryan Henderson
2008-01-17 22:45 ` Theodore Tso
2008-01-17 22:58 ` Alan Cox
2008-01-17 23:18 ` Ric Wheeler
2008-01-18 0:31 ` Bryan Henderson
2008-01-18 14:23 ` Theodore Tso
2008-01-18 15:16 ` [Patch] document ext3 requirements (was Re: [RFD] Incrementalfsck) linux-os (Dick Johnson)
2008-01-19 14:53 ` Pavel Machek
2008-01-18 15:26 ` [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck) Ric Wheeler
2008-01-18 20:34 ` Jeff Garzik
2008-01-18 22:35 ` Bryan Henderson [this message]
2008-01-18 15:08 ` H. Peter Anvin
2008-01-18 17:43 ` Bryan Henderson
2008-01-16 21:28 ` Eric Sandeen
2008-01-16 11:51 ` Pavel Machek
2008-01-16 12:20 ` Valdis.Kletnieks
2008-01-19 14:51 ` Pavel Machek
2008-01-16 16:38 ` Christoph Hellwig
2008-01-16 1:44 ` Daniel Phillips
2008-01-16 3:05 ` Rik van Riel
2008-01-17 7:38 ` Andreas Dilger
2008-01-16 11:49 ` Pavel Machek
2008-01-16 20:52 ` Valerie Henson
2008-01-17 12:29 ` Szabolcs Szakacsits
2008-01-17 22:51 ` Daniel Phillips
2008-01-15 1:04 ` [RFD] Incremental fsck Ric Wheeler
2008-01-14 0:22 ` Daniel Phillips
2008-01-09 8:04 ` Valdis.Kletnieks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OFDAE81670.76D5065A-ON882573D4.007A239B-882573D4.007C23CE@us.ibm.com \
--to=hbryan@us.ibm.com \
--cc=a1426z@gawab.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dgc@sgi.com \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=phillips@google.com \
--cc=ric@emc.com \
--cc=riel@redhat.com \
--cc=tytso@mit.edu \
--cc=val.henson@gmail.com \
--subject='Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck)' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).