[Yaffs] Sorry state of YAFFS1 :((

[Charles Manning]

On Sunday 18 September 2005 11:25, Sergey Kubushyn wrote:

> 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. 

That is not necessarily true. It depends on what you have enabled in mtd.

> 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. 

These warnings are trying to tell you something. If you just ignore them then 
expect problems.

If you are getting these, then it suggests that both mtd and YAFFS are doing 
ECC or that the mtd is mashing something so that the ECC fields being used by 
YAFFS are incorrect.

> 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.

There are some areas of unfriendliness in that the warnings being generated 
are bogus. There is no "trust me I know what I am doing" flag that you can 
pass into mtd to make this shut up. 

There are also an issue with the verification and how this interacts with the 
writing of deleted flags markers.

The nand_oobinfo method is broken as a general solution because it needs to be 
tweaked to match the hardware + nand driver being used. If you are using, for 
example, hardware ECC that uses some different location then the nand_oobinfo 
needs to be changed to work with that. These differences have made it hard to 
get one set of working settings.  

The newer strategy is far cleaner since it does not rely on any particular 
placement but uses AUTO_PLACE. Actual placement is thus handled in one place 
only and YAFFS gets cleaner. There are still some issues because, AFAIK, the 
AUTOPLACE stuff is not yet fully implemented in mtd. This is what is holding 
back the shift to AUTOPLACE and a far cleaner future.

All the testing I have done personally on yaffs in the kernel uses code that 
conforms to the NAND mtd interface, but does not use the mtd nand code behind 
the scenes. Thus, for real interactions with the mtd nand code I have had to 
rely on community feedback. I think I should also use the nand simulator to 
be able to reproduce this entirely myself.

Charles