[Yaffs-archive] Re: YAFFS: mkyaffsimage etc

[Charles Manning]

On Wednesday 25 June 2003 06:55, you wrote:
> Thank you so much for all your help Charles,
>
> In case you're curious.  I have successfully flashed a filesystem image
> from the bootloader.  The YAFFS image was created by cross compiling
> mkyaffsimage (PPC32).  I then mounted an root filesystem from x86 and ran
> mkyaffsimage on the device on a NFS directory.  After flashing the image
> from the bootloader there are still some problems.  I have about 5 objects
> that are in the lost+and+found, the same objects verified on 2 different
> devices (probably not bad block related).
>
> I'm assuming at the moment that the problem lies in the mkyaffsimage util,
> but not sure what is going wrong as I used a natively built mkyaffsimage.
> I'll keep you updated.
>
> Chris

Chris

That's a sneaky way of doing it :-).

Question 1: Once you've mounted the YAFFS image, does it work fine with 
subsequent read/write/delete etc activity. ie. is it just the original image 
files that got screwed up?

Question 2: What is the magnitude of the objxxx filenames? YAFFS starts 
allocating these at 256. 

I'll explain a bit about this:  YAFFS scanning 101.

As YAFFS scans the device (on mount), it reads the chunks.
If a chunk discarded/deleted it is ignored. Otherwise it looks at the tags 
which tell it whether the chunk is an object header or file data chunk.

If it is a file data chunk then it looks at the file id and chunkId (offset 
into file). If YAFFS already knows about the file with this id, then the 
chunk is just added to the tree for that file. If, however, the file is not 
already known about, then a file entry with that id is created.  If the 
file's parent (ie the directory it is in) is not known about then we just 
create the file in lost+and+found (LNF).

If, however, the chunk is an object header, this tells us the file name etc 
and who its parent is. This helps us create the directory stucture.
The file might already exist (created already in LNF as per above) and the 
directory structure is rectified.

When scanning is complete, everything should be sorted out and there should 
be nothing in LNF.

The only reasons you will find things in lost and found are the following:

* Data chunks for which there are no corresponding object entries:  These 
will appear as files named objnnn where nnn is the object id (==inode) of the 
file.

* Files who do not have parents (ie. parent directory is missing): These will 
be of the form  objnnn/filename. THis means that file filename thinks its 
parent should be object nnn, but this object does not exist.

This could potentially be caused by data corruption of these fields, but 
it is highly unlikely. More likely one of the following is happening:

* You're getting some endian mismatching issue (including bitfield 
mismatching).
* You're somehow mismatching the area of NAND (ie. yaffs is not scanning some 
of the data chunks where you wrote the image and thereby getting some missing 
data).

If you can't make any headway with some effort, plz feel free to send me a 
**small** image (say a directory or two with a few small files, links etc) 
and a matching tar file. Send direct to me to not snow the list.

-- Charles



---------------------------------------------------------------------------------------
This mailing list is hosted by Toby Churchill open software (www.toby-churchill.org).
If mailing list membership is no longer wanted you can remove yourself from the list by 
sending an email to yaffs-request@toby-churchill.org with the text "unsubscribe" 
(without the quotes) as the subject.