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
(text/plain)