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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.