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 that 
YAFFS scanning could find the directory that myfile belongs to and it got 
dumped there instead. Well actually it will be dumped in 
.../lost+found/objxxx/myfile.txt).
2) If the file name is something like objnnnn then it means that YAFFS found 
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 
time from the objectId of the chunk. Thus, obj17170432 tells us that a chunk 
turned up marked with objectId 1717042.  Now objectIds are created 
sequentiually starting at 4096, and I don't believe that 1717000-odd files 
have been created on this system, which says to me that the objectId in the 
tags got corrupted.

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

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

-- Charles