ts-7000
[Top] [All Lists]

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

To:
Subject: [ts-7000] Re: YAFFS - Recovering from a full onboard flash
From: "Steve Hier" <>
Date: Tue, 28 Mar 2006 03:56:52 -0000
I find I too am in this situation.

It would be very useful if you could post the modified kernel /
eraseall utility.

Thanks.

--- In  "Eddie Dawydiuk" <> 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
> 
> 
> > --- In  "Eddie Dawydiuk" <eddie@> wrote:
> >>
> >> Hello,
> >>
> >>> I had a wayward program of mine fill up the 128MB of onboard
> > flash
> >>> on my TS-7250, basically by writing data a bit quicker than I
> >>> thought it was. When I got back to it a 'df' showed that it was
> > 85%
> >>> full, so I tried deleting a few older files to clean up some
> > space.
> >>> While deleting some files I got error messages to the effect
> >>> of 'Directory not empty' (even though it was only a few _files_
> > that
> >>> I was deleting). Anyway, the files are now gones from a directory
> >>> listing, but the space wasn't free'd in the 'df' output.
> >>>
> >>> So I've tried looking at 'dmesg' output and it tells me ...
> >>>
> >>> !!!!!!!!! Allocator out !!!!!!!!!!!!!!!!!
> >>> yaffs tragedy: no space during gc
> >>>
> >>> Also, i'm not sure if this is relavent but there are messages in
> >>> there about bad blocks too. I know these are normal but I'm not
> > sure
> >>> what a *normal* amount of bad blocks would be. I have approx
> >>> 220 'block XXXX is bad' lines in dmesg, and some amount (more
> > than
> >>> 20, the start of dmesg is truncated) 'Bad eraseblock XXXX at
> >>> 0x0yyyyyyy' messages. The block numbers correspond in most cases.
> >>>
> >>> I now can't write anything to the flash, or delete files, etc.
> > I've
> >>> searched a bit on google for filesystem checking utilities
> > hopeing
> >>> that something can recover lost blocks but can't find anything.
> >>>
> >>> Has anyone had this problem, or know of a way to fix? I'd greatly
> >>> appreciate any advice!
> >>
> >> We have seen this problem in the past. We've spoken to Charles
> > Manning
> >> (main Yaffs developer) regarding this problem. He is working to
> > correct
> >> this problem... Any information you could supply Charles would help
> >> him to solve this problem. Yaffs mailing list
> >> http://www.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
> >>
> >> BTW I have a kernel and userspace program that will allow you to
> >> recover bad blocks...
> >>
> >> //Eddie
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>






 
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