[Yaffs-archive] RE: YAFFS Pecularities in directory after remount

[Christian Gan]

Hey Charles,

Thanks for the response, I've been busy with other things and haven't had
the chance to try a few things out until today.

My responses are below preceded by "CGAN:".

Christian Gan

-----Original Message-----
From: Charles Manning [mailto:manningc2@actrix.gen.nz]
Sent: Wednesday, August 21, 2002 2:46 AM
To: Christian Gan; YAFFS list
Subject: Re: YAFFS Pecularities in directory after remount


>
> I'm new to the list so don't mind me if I'm just repeating something
that's
> been said already but... here goes:

No worries Christian, the list is pretty young, so once you've posted more
than about twice you're a seasoned pro.

CGAN: Great, can I get a t-shirt or something now? :)

>
> Equipment:
>
> Custom ARM720 core SBC running Linux (2.4.6), MTD is upgraded to newest
> version.
> Toshiba 16MB NAND flash w/ HW ECC (through custom FPGA design).

This is pretty funky hardware. Most yaffs setups are using raw NAND without
FPGA etc. Questions:
* Is the flash still 512 data bytes + 16 bytesOOB per page and 32
pages/block?
* Does the FPGA use any of the OOB for its own purposes? Maybe this is
preventing the YAFFS tagging from working properly. See below.

CGAN: Yes, our board is built with many IOs, we thought it would save us
some lines to the ARM if we funnel the interface through the FPGA.  This
also allowed us to implement our own HW ECC as well as connect multiple
NANDs that share the same CLE, ALE, WE, etc lines (FPGA takes care of the
timing).

CGAN: As to your other questions:
- Yes the flash is still 512 data byes + 16 bytes oob and 32 pages/block.
- No the FPGA does not actually write to the OOB itself, it just passes back
the ECC value in a register that can be read.

>
> Question 1:
>
> I managed to get the MTD and yaffs working after tweaking both to match
our
> interface to the NAND (via the FPGA).
>
> Here's the breakdown:
> 1.  Copy a file onto the yaffs directory.
> 2.  Delete it.
> 3.  Copy another file into the directory with the same name.
> 4.  Reboot and remount the yaffs directory.
>
> What I sometimes find now is that the file is there but the size is 0.
> Anyone else see this?

OK. I just tried this out using yaffsram on my PC with the currently checked
in code and I did not get this problem. The only difference between yaffsram
and yaffs on mtd is that yaffsram emulates the mtd with RAM.

Assumptions:
* You're working with the latest code.
* You umounted the YAFFS fs before the reboot.

CGAN: Hmmm, I was not unmounting the device before I rebooted.  I tried a
few preliminary tests and it SEEMS that things are okay and I do not get the
0 length files.  I had thought the serial number algo in YAFFS takes care of
situations like this when power goes down unexpectedly.  What happens during
a umount that may explain this?

In a nutshell here's a quick explanation of how YAFFS works on the media and
thus what might be happening.

YAFFS stores everything as 512byte+16byte OOB "chunks". Chunks can be
ObjectHeaders (ie. named entities) or file data chunks.
Each Object has an objectId. The ObjectHeader chunk is tagged with
ObjectId:0
and data and other status info. Tags live in the OOB area.

When an chunk becomes invalidated (when overwritten or deleted), it gets
marked as deleted (by setting a byte in the OOB area). When all the chunks
in
a block get deleted, the block is erased and reused.

Now let's walk through what happens when we do what you did.
* Copy file. This has the following sub-steps:
 - Create file: Makes an ObjectHeader for the file. Length 0.
 - Write data to file: Writes a bunch of file data chunks.
 - Close/flush file: Writes an updated object header with the right length
and deletes the old one.
 * Delete file: Deletes the file data chunks and the ObjectHeader for the
file.
* Create new file does the above all over agian.

On the flash, we now have more than one ObjectHeader for the file, but all
except one should be deleted.

While all the data structures are in RAM relative sanity prevails.

When the device is rebooted it needs to scan the media to reconstruct the fs
state. You can see what it does in yaffs_Scan(). Basically it just iterates
over the pages in flash ignoring unused and deleted chunks. As it encounters
valid chunks it reconstructs the state.

Now, here's my theory... Maybe the deletion is not working properly (because
perhaps your FPGA is using bytes that YAFFS wants to use for tags) and when
the scanning is done,  more than one ObjectHeader is read and the wrong
ObjectHeader (the zero length one) is being used by mistake.

To test this theory, could you turn on some of the tracing in yaffs_Scan and
see if that tells anything (eg. see if you get multiple ObjectHeaders for
the
same file).

>
> Question 2:
>
> I also find that when I keep copying files into the directory until it is
> full, the last copy will be stuck in an infinite loop.

Yup looks like a problem. Thanx. I thought I'd fixed this. I'll look into
this ASAP.

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


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