From: Bob Canup <rcanup@go2fax.com>
To: mtd@imladris.mvhi.com
Subject: Flash reliability
Date: Tue, 30 Nov 1999 08:38:14 -0600 [thread overview]
Message-ID: <3843E156.7CF8945B@go2fax.com> (raw)
Vipin Malik wrote:
>
> *(subscript).Actually, I'll disagree with the statement that "regular"
> disks suffer from these same issues (to the same extent). To test the
> effect of power fail under ext2 under Linux, I have done some extensive
> (20K+) power cycles on various media.
> The media used were the M-sys IDE2000 flash IDE disks, a "regular"
> desktop harddrive, and a compact flash card.
> Now, both the compact flash and the IDE (m-sys) suffered from a
> catastrophic failure of (some) particular block suffering from some sort
> of "low level" failure (that mainsfested itself as a CRC error or sector
> unreadable error in trying to read it). e2fsck, nor any other utility
> was successfull in recovering from this problem, as the low-level IDE
> block driver bailed out due to this problem.
> The "regular" hard drive did NOT suffer from this problem. I never had a
> situation in which e2fsck -f -y /dev/hdaxx did not manage to repair the
> file system to a usable state.
>
> I did manage to come up with a way to "repair" this system, but that
> would result in a completely blank block of 512 bytes. If this block
> contained 4 inodes, I could (and did) loose upto 4 files or even
> directories and everything under them. Obviously not acceptable.
>
I think that expecting ANYTHING to function properly during power failure is
wishful thinking. I also suspect that the fact that the rotating media did not
exhibit the failures that the flash based system did has to do with probabilities;
because flash writes take much longer to occur than writes to a rotating disk the
probability of randomly encountering a condition where a failure occurs is lower on
a faster writing medium.
Even battery backed up static ram can be trashed if power loss occurs during a
write to the chip.
The only ways that I see to handle the problem are: 1. Run the flash as a Read Only
system. 2. Have a power fail detect signal which detects that the power is going
down , signals the system to flush the buffers, and holds up the power to the
system long enough for that flush and subsequent ordered shutdown to occur.
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
reply other threads:[~1999-11-30 14:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3843E156.7CF8945B@go2fax.com \
--to=rcanup@go2fax.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