ts-7000
[Top] [All Lists]

Re: [ts-7000] Re: YAFFS - Recovering from a full onboard flash

To:
Subject: Re: [ts-7000] Re: YAFFS - Recovering from a full onboard flash
From: "Jesse Schwartzentruber" <>
Date: Fri, 2 Jun 2006 14:11:22 -0400
I am getting a lot of bad blocks when untarring a lot of files to
flash where it would overwrite existing files, and i also got it from
doing `rm -rf /mnt/mtdblock2/*`
I am using kernel 2.6.17-rc5 with yaffs2 cvs from 20060531 on a TS7250
with 32Mb flash. Also, I am using the nand ecc; should I be using the
yaffs ecc?

- Jesse

On 6/2/06, 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 --------------------~--> 
Get to your groups with one click. Know instantly when new email arrives
http://us.click.yahoo.com/.7bhrC/MGxNAA/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/
 



<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU