Re: [Yaffs] Sorry state of YAFFS1 :((

Startseite
Anhänge:
Nachricht
+ (text/plain)
Nachricht löschen
Nachricht beantworten
Autor: Sergey Kubushyn
Datum:  
To: Charles Manning
CC: yaffs
Betreff: Re: [Yaffs] Sorry state of YAFFS1 :((
On Sun, 18 Sep 2005, Charles Manning wrote:

> On Saturday 17 September 2005 11:55, Sergey Kubushyn wrote:
> > Hi!
> >
> > OK, I've been absent for a while and what I see is that YAFFS1 is
> still in
> > that same sorry state :((
> <snip a whole bunch of sometimes true and sometimes abusive stuff>
>
> I hope that was good therapy for you Sergey.
>
> Yes, some of what you say is somewhat true. YAFFS and mtd often work
> well
> together and currently need quite a bit of manual effort to get them
> working
> together. There is quite a bit of howto info on this, particularly the
> stuff
> by Nick Bane, so this is typically not too hard to do.


I'm not new to YAFFS and I do know how it works. MTD doesn't have anything
to it if one uses YAFFS ECC. As a matter of fact it looks like YAFFS1 DOES
work properly because my simple test with copying a file to it, then
removing it in an infinite loop worked just fine for 24 hours. Both with
YAFFS and MTD ECC. But every single read and write produces a whole bunch of
those "**>>ecc error unfixed" and "**>Block XYZ marked for retirement"
messages. Wneh using MTD ECC /proc/yaffs shows 1 in "tagsEccUnfixed",
"eccFixed" and "eccUnfixed" both stay at 0. They are growing when using
YAFFS ECC. For me it looks like those are not errors per se but some bugs in
_REPORTING_ errors. Unfortunatelly I don't have time to fix it, we're facing
a deadline and there is a lot to be done besides YAFFS.

> Outside of the mtd interfacing issues I can assure you that YAFFS (1
> and 2)
> work very well and provide a storage backbone for many high-reliability
> products. Those that are not using mtd (ie. are using YAFFS outside of
> Linux)
> generally have a much simpler time.
>
> The YAFFS2 stuff is generally a lot cleaner because it uses the new mtd
> model.
> A few changes are still required to the mtd to use the new model for
> 512-byte
> page devices with YAFFS1. When those changes are in place YAFFS1
> interfacing
> should become a lot cleaner. Behind the scenes there has been quite a
> bit of
> effort trying to straighten out issues by trying to get mtd to be more
> YAFFS
> friendly.


I don't see how MTD might be unfriendly. Just pass a proper nand_oobinfo to
read/write_ecc and that's it. That is when using MTD ECC. When YAFFS ECC is
used there is no problems at all, MTD does NOT do any error checking,
everything is done in YAFFS guts. So no matter how one "fixes" MTD if YAFFS
itself generates error messages the problem is definitely inside YAFFS code
and in no way related to MTD. There are complains from MTD that is not wise
to read/write data without ECC, but they are harmless and they are supposed
to be output because YAFFS really reads/writes data without ECC.

---
******************************************************************
*  KSI@home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************