[Yaffs] YAFFS2 failure

[Charles Manning]

Some points to mention...

> Listing lost+found gives:
> # ls /mnt/lost\+found/
> ls: /mnt/lost+found/obj17170432: Value too large for defined data type
> ls: /mnt/lost+found/obj17235968: Value too large for defined data type
> ls: /mnt/lost+found/obj17301504: Value too large for defined data type
> [etc...]
>

Stuff turns up in lost+found when the directory structure can't handle it=
.

Stuff in lost+found shows up in two ways:
1) If the name looks sane (eg. .../lost+found/myfile.txt) then it means t=
hat=20
YAFFS scanning could find the directory that myfile belongs to and it got=
=20
dumped there instead. Well actually it will be dumped in=20
.../lost+found/objxxx/myfile.txt).
2) If the file name is something like objnnnn then it means that YAFFS fo=
und=20
some data chunks, but could not find a file name to associate with them.

We're observing 2 above.

It is also worth noting that the nnn in obj nnn is made up by YAFFS at ls=
=20
time from the objectId of the chunk. Thus, obj17170432 tells us that a ch=
unk=20
turned up marked with objectId 1717042.  Now objectIds are created=20
sequentiually starting at 4096, and I don't believe that 1717000-odd file=
s=20
have been created on this system, which says to me that the objectId in t=
he=20
tags got corrupted.

All this is very consistent with the mtd problems discussed by others her=
e. I=20
believe this has been fixed in mtd CVS.

As a side issue: I have finally got around to purchasing a new coimputer =
to=20
be loaded with Linux 2.6. It has 1GB of RAM which means I should be able =
to=20
do proper mtd emulations of up to, say, 512MB of NAND. I hope this will b=
e=20
able to help me do a better job of improving mtd and 2.6 integration.

-- Charles