From: Vipin Malik <vmalik@danielind.com>
To: MTD <mtd@imladris.mvhi.com>
Subject: [Fwd: Power Down]
Date: Wed, 08 Dec 1999 15:36:55 -0600 [thread overview]
Message-ID: <384ECF77.C1F5D6FC@danielind.com> (raw)
Bob Canup wrote:
>
> It is obvious that a physical medium such as a disk is vulnerable to
> having a bad sector created by the process that I described. The proof
> is simple: pop out a diskette while you are writing to it and you stand
> a good chance of creating a sector in which the CRC and data are out of
> sync. When you attempt to read the sector you will get a bad CRC.
>
> This occurs in a diskette because the writing process is a serial event;
> it is spread over time. So there is a window in which an interruption
> can create a bad sector.
>
> Let us assume the the DOC writes all of the bytes in a page including
> the ECC code in parallel, let us also assume that you have an internal
> bit which marks a sector as good when that process has completed. There
> nevertheless is a time during the 'burn' of the bits where we are in an
> analog state of changing the bits. If power is lost at that time - some
> of the bits will not have changed to their proper state. Even if the
> page is not marked as good an attempt to read the page will result in an
> ECC and data which do not match and the result is a bad sector. The
> sector may be easily recovered by erasing it and starting over - but as
> long as there is an analog aspect to changing the states - the bits will
> not all change at the same instant and a window for corruption exists.
Ah! buy having a CRC on the *ENTIRE* sector gets around this problem.
Unless ALL the bits are burned in, the CRC will not match on a read.
As to what happens the next time power comes back on, I guess that one
does not erase the "good" sector till the new one is completely written.
This way, at least you have the last (old) data still available.
>
> Vipin's original post said that he saw bad sectors about once in every
> 250 power down cycles. Oran is telling us that can't occur.
I mailed a detailed post about this one a few mails ago. Plese refer
that.
>
> Of course if my analysis is correct then you are safe to erase the bad
> sector - it was the last one being written; the file system would then
> be left in a state in which e2fsck could hopefully repair it.
Unfortunately, if the lower layer driver does not know WHAT goes in that
sector (inodes, data, etc), it could end up erasing a sector with inodes
in it. This is something that e2fsck will not be able to recover from
(at least without potentially killing a bunch of files on the system).
>
> Or am I off in left field with this?
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
next reply other threads:[~1999-12-08 21:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-12-08 21:36 Vipin Malik [this message]
1999-12-08 23:02 ` [Fwd: Power Down] Bob Canup
1999-12-09 11:02 ` David Woodhouse
1999-12-09 14:56 ` Bob Canup
1999-12-20 4:22 ` Stuart Lynne
-- strict thread matches above, loose matches on Subject: below --
1999-12-08 21:39 Vipin Malik
1999-12-08 21:32 Vipin Malik
1999-12-09 11:10 ` David Woodhouse
1999-12-08 20:48 Vipin Malik
1999-12-08 20:42 Vipin Malik
1999-12-07 16:36 [Fwd: power down] Oron Ogdan
1999-12-06 23:41 Vipin Malik
1999-12-07 15:47 ` Bob Canup
1999-12-20 4:03 ` Stuart Lynne
1999-12-07 20:36 ` Jon Burford
1999-12-13 14:49 ` Adi Linden
1999-12-13 19:07 ` Jon Burford
1999-12-08 15:10 ` David Woodhouse
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=384ECF77.C1F5D6FC@danielind.com \
--to=vmalik@danielind.com \
--cc=mtd@imladris.mvhi.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox