Some ideas and questions:
Rather than retiring a block with a bad ECC, could you flag it for future
testing?
You'd move all the valid pages out of the block then erase and test the block?
Maybe you could keep an error count for each block, if the blocks were flagged
too often they'd get retired?
Or what if the flagged blocks where kept aside and not used till the file
system was out of good blocks? Then writing would slow down, but you'd still
have access to those blocks, and people who don't use the whole file system
won't suffer.
If one page has a bad ECC does that indicate that the whole block is bad? or
just that page?
Can you retire individual pages in the block without retiring the whole block?
-Curtis.
On June 2, 2006 12:40 am, embeddedjanitor wrote:
>
> Hi
>
> I'm Charles Manning, the bloke that wrote YAFFS....
>
> Unless you keep current with the YAFFS CVS, you're unlikely to have
> some of the newer YAFFS2 features. I also use a TS7250 (128MB 2kbyte-
> per-page NAND) as a test board. If there's an interest I can post a
> yaffs2 tree for TS7250 that is patched to the current level.
>
> To follow up on the bad block issue... There are basically two ways a
> block can get to be bad:
> 1) Marked bad in the factory. These are real bad blocks and should not
> be erased.
> 2) Software-marked bad blocks. It should be OK to erase these.
>
> YAFFS uses a very conservative policy to marking bad blocks. If a
> block shows any ECC errors then it is retired. This is more
> conservative than, say, SmartMedia which will only retire blocks that
> give writing/erasing errors.
>
> The rationale behind this more conservative policy is that I'd rather
> lose some blocks than lose data. However, some NAND chips
> (partitulcarly newer ones) seem yo display single-bit ECC errors quite
> regularly and retiring these blocks reduces the size of the fs too
> fast.
>
> I have started an effort to modify the retirement policy to try find a
> middle ground (don't retire as soon, but still maintain data
> integrity).
>
> I am very interested in any experiences people have in how to stress
> the system to force failures (rather than just doing read/write for a
> week or two and looking for errors).
>
> Thanx
>
> -- Charles
>
>
>
> --- In "Jesse Schwartzentruber" <>
> wrote:
> >
> > I had 71% used by bad blocks after doing `rm -rf /`
> >
> > this worked great though, thank you.
> >
> > On 6/1/06, Eddie Dawydiuk <> wrote:
> > > Hello,
> > >
> > > > I have encountered this problem too. Eddie, could you post or
> send me
> > > > your solution?
> > >
> > > You can download a modified eraseall utility, and modified kernel
> > > source code that will allow you to erase blocks marked as bad
> > > here ftp://oz.embeddedarm.com/tmp/erase_BB/. I haven't tested the
> > > modified kernel source code, let me know if you see any problems.
> > >
> > > //Eddie
> > >
> > > > --- In "Eddie Dawydiuk" <eddie@> wrote:
> > > >>
> > > >> Hi Phil,
> > > >>
> > > >>> Now I am just interested in the amount of "bad blocks" that I
> have.
> > > >>> There are 223 bad blocks which equates to ~3.5MB unusable. Is
> this
> > > >>> an expected number given that my board is 9 months old, and I
> > > >>> wouldn't have thought my usage of the onboard flash was
> particularly
> > > >>> severe. My application basically writes data to the flash, and
> then
> > > >>> periodically when the flash is near filling up, I transfer it
> out
> > > >>> and delete the data. I have probably gone through no more the
> 3
> > > >>> cycles of filling it up with data, transferring the data,
> deleting
> > > >>> the data.
> > > >>>
> > > >>> Also, is it correct that any "bad blocks" are flagged when
> erasing
> > > >>> the flash and throw error messages like ...
> > > >>>
> > > >>> "eraseall: /dev/mtd/1: MTD Erase failure: Input/output error"
> > > >>>
> > > >>> or is this indicating a different problem. (I get 223 of the
> above
> > > >>> messages, one for each bad block). Is it possible that these
> blocks
> > > >>> have just been incorrectly flagged as bad, when I had the
> problem
> > > >>> that I originally posted about?
> > > >>
> > > >> I believe they may have been incorrectly marked bad, this is
> what
> > > >> I was refering to in the last email. That is I have seen when a
> > > >> large number of files(tens of thousands of files) are created
> on
> > > >> Yaffs1, when you try to recursively delete the files some of
> the
> > > >> files will not delete reporting the directory is not empty.
> Yaffs
> > > >> will try several times to delete the file and end up marking
> the
> > > >> block as bad. This is the problem I have mentioned to Charles
> > > >> Manning about Yaffs1. The more information you could provide
> him
> > > >> the better...
> > > >>
> > > >> Typically 1-2% of bad blocks marked bad is normal. You have
> > > >> 223 / 8000 => 2.78 % this is somewhat high.
> > > >>
> > > >>> And if so would the programs you mentioned in your reply help
> here?
> > > >>> If so, where would I be able to obtain these programs?
> > > >>
> > > >> The eraseall utility as well as the mtd device drivers will
> refuse
> > > >> to delete any blocks marked bad. I have hacked the mtd drivers
> as
> > > >> well as the mtd device driver so you can delete blocks marked
> bad.
> > > >> I'll email the kernel and eraseall utility if you'd like...
> > > >>
> > > >> //Eddie
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Everything you need is one click away. Make Yahoo! your home page now.
http://us.click.yahoo.com/AHchtC/4FxNAA/yQLSAA/CFFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|