The blocks are first marked in the RAM structures for retiring. Often this
cannot be done immediately because there is stil data on the blocks. Thus
it is deferred to being handled as part of a garbage collection.
If the RAM data is lost (eg. power cycle), then that is not a problem. This
will be detected again on the next read.
Have a look at the HowYaffsWorks document. That might help explain things a
bit more.
-- Charles
On Mon, Mar 5, 2018 at 7:59 PM, de Brebisson, Cyrille (Calculator Division)
<
cyrille@hp.com> wrote:
> Hello,
>
>
>
> Yet another question. When/How will the block that caused a read/write
> error be retired.
>
> The issue at hand here is the following:
>
> Read error occurs. Bad data is returned to the application that was
> reading the data. This causes a crash. Because we are on a small, one app
> RTOS, the whole system crashes.
>
> If yaffs has “retired” the block “in it’s own private structures”, but not
> committed this to flash, then this “knowledge” will be lost and the block
> will not be retired.
>
>
>
> Are we in this scenario?
>
>
>
> Cyrille
>
>
>
> *De :* de Brebisson, Cyrille (Calculator Division)
> *Envoyé :* Thursday, March 01, 2018 7:09 AM
> *À :* Charles Manning <cdhmanning@gmail.com>
> *Cc :* yaffs@stoneboat.aleph1.co.uk
> *Objet :* RE: [Yaffs] New to the mailing list. Have issues with bad flash
> reads
>
>
>
> Hello,
>
>
>
> I have some more questions that are popping up as I continue investigating
> this “flash read fails” issue.
>
> You said that when bad read are detected, the block will be marked for
> later “cleanup”….
>
> - Do you mean that the block will be reused, or retired (marked as bad)
> - How is this done?
> - Is it done through internal YAFFS memory structures (which will not
> survive a “format through erase all blocks”)? Or is this done through a
> “bad block marking”?
>
> In my latest test, I have 256 pages that return bad reads, in 4 different
> blocks
>
> - but I have not seen yaffs doing any bad block markings. Is this
> normal?
> - When will yaffs mark block as bad? In which condition and at what
> time?
>
>
>
> Thanks,
>
> Cyrille
>
>
>
> *De :* yaffs [mailto:yaffs-bounces@stoneboat.aleph1.co.uk
> <yaffs-bounces@stoneboat.aleph1.co.uk>] *De la part de* de Brebisson,
> Cyrille (Calculator Division)
> *E**nvoyé :* Thursday, February 22, 2018 7:37 AM
> *À :* Charles Manning <cdhmanning@gmail.com>
> *Cc :* yaffs@stoneboat.aleph1.co.uk
> *Objet :* Re: [Yaffs] New to the mailing list. Have issues with bad flash
> reads
>
>
>
> Hello,
>
>
>
> Thank you for the info on yaffs’s handling of bad read. I understand what
> you mean here.
>
>
>
> About the bad flash drivers.
>
> - One area where people often make mistakes is in waiting until the
> data is properly ready before reading.
>
> I do not think that this is the issue as we are using a nand flash signal
> pin to know when data is ready to read
>
> - Also, make sure the flash memory power supplies are good and low
> ripple.
>
> This sounds like a much more likely root cause in our case. I will
> investigate. Thanks for the pointer
>
>
>
> Thanks for the info.
>
> Have a good day.
>
> Cyrille
>
>
>
> *De :* Charles Manning [mailto:cdhmanning@gmail.com <cdhmanning@gmail.com>]
>
> *Envoyé :* Wednesday, February 21, 2018 10:37 PM
> *À **:* de Brebisson, Cyrille (Calculator Division) <cyrille@hp.com>
> *Cc :* yaffs@stoneboat.aleph1.co.uk
> *Objet :* Re: [Yaffs] New to the mailing list. Have issues with bad flash
> reads
>
>
>
> Hello
>
> You really have two independent, but related issues going on here...
>
>
>
> On Thu, Feb 22, 2018 at 4:45 AM, de Brebisson, Cyrille (Calculator
> Division) <cyrille@hp.com> wrote:
>
> Hello,
>
>
>
> I am responsible for implementing yaffs in a small, bare meta OS system
> with a 512MB, 2K pages, 64 pages block NAND Flash.
>
>
>
> Our Flash rom subsystem is sometimes failing reads. This is happing on
> blocks that are supposed to be good and contains file data! Furthermore,
> later reads to the same page might succeed (after a system reboot).
>
>
>
> Of course, this is wrecking havoc on our system’s reliability.
>
>
>
> So, a couple of questions:
>
> - have you ever seen that in your experience?
>
>
>
> Bad flash drivers are quite common. One area where people often make
> mistakes is in waiting until the data is properly ready before reading.
>
> Also, make sure the flash memory power supplies are good and low ripple.
> Remember that cells (and NAND flash cells in particular) are really
> analogue elements and too much ripple on the power rails can cause problems.
>
>
>
>
> -
> - when this happen, I make sure that the flash driver to yaffs
> interface returns a YAFFS_FAIL, however, yaffs does seem to still return
> data to the user that called the file read, incorrectly returning known bad
> bytes at this point. Is this normal?
>
> Yes, there is an issue here. Yaffs can choose to either say there is an IO
> error (EIO) or it can try to give back as much data as it can. Yaffs
> chooses the latter approach.
>
> I have some changes underway to allow Yaffs to return EIO instead.
>
>
>
>
> -
> - After such a bad read, yaffs does not seem to do anything on the
> block like mark it as bad or something like this. Is it intended?
>
> It should be marked for future cleanup.
>
>
> -
>
>
>
> I am working with a checkout of yaffs which is around 6 month old (taken
> in june 2017) in a bare metal setup.
>
>
>
> I doubt there are significant changes in the last 6 months to impact this
> issue.
>
> The major thing to do is find out why the flash reads are failing so badly.
>
> Regards
>
> Charles
>
(text/plain)