[Yaffs] Why does YAFFS skip the first block?

[Charles Manning]

On Wednesday 22 June 2005 12:13, Peter Barada wrote:
<snip>
> > All is not lost though, there is a way to use that block zero,  and i=
t is
> > pretty straight forward. You just need to tell YAFFS some lies!
> >
> > All yaffs flash calls go through a few access functions.
> > All you need to do is to do a mapping in these functions so that yaff=
s
> > block 1 =3D physical block 0.
> >
> > eg.
> > int (*writeChunkToNAND)(struct yaffs_DeviceStruct *dev,int chunkInNAN=
D,
> > const __u8 *data, yaffs_Spare *spare)
> > {
> >       chunkInNAND -=3D dev->nChunksPerBlock;
> >
> >      .....   // rest of stuff
> > }
> >
> > int (*eraseBlockInNAND)(struct yaffs_DeviceStruct *dev,int blockInNAN=
D)
> > {
> >     blockInNAND--;
> >     ...// rest of stuff
> > }
> >
> > Now you must need to keep the illusion going by setting up the device
> > start and end blocks accordingly. If you have, say, 32 physical block=
s
> > numbered from 0 to 31, then just set up startBlock=3D1 and endBlock =3D=
32;
> >
> > There is no chunk or block info imprinted in the actual YAFFS data, s=
o no
> > changes are needed to mkyaffsimage etc to make this work.
>
> Ugh, that sounds like a *total* hack. =20

So what? It is very simple, works fine, is efficient and does not disrupt=
=20
stable code.

As it is, you're already pulling nastier hacks to emulate spare regions e=
tc=20
to make NOR look like NAND.

>Is there anything wrong with
> allowing dev->startBlock to be zero instead of 1?

This would not work for various things.=20
For example when YAFFS goes to look for the chunkId of the chunk in chunk=
=20
zero, the search code  would report "it is in chunk zero" which the rest =
of=20
yaffs interprets as "it does not exist". So anything you write to chunk z=
ero=20
is written into a black hole.


>
> I *could* do the remap in the access functions, but it *assumes some
> magical offset that requires a comment of:
>
> 	/* This is a total hack since YAFFS refuses to use block zero */

Hack, maybe. Total hack, I think, is stating it a bit strongly.

Any offset is fine so long as there is no logical (ie from YAFFS's point =
of=20
view) chunk zero any more. Just using a one block offset is the simplest=20
case. Counting from one instead of zero is hardly going to make most=20
programmers spill their cup of tea.

You can just use fixed constants in your mapping: Offset by one block. Si=
nce=20
dev->nChunksPerBlock holds the number of chunks per block that is all you=
=20
need to offset by for the reading/writing of a block.

This means, all up, you need to add three lines of code:=20

    blockId--; // add to the erase function

    chunkId -=3D dev->nChunksPerBlock; // add to read/write functions

And change two lines where you set the start and end blocks.

Changing five lines of code is hardly a large effort. Much less than, say=
,=20
writing an email.


>
> Is there anything *actually* wrong with using block zero?  If what you
> say is true for NAND, then you don't even bother using the one
> guaranteed good block in the device...

There is nothing technically wrong with using block zero from a memory/NA=
ND=20
perspective.  At the end of the day, file system integrity is governed by=
 the=20
performance of the worst block and not the best block. Block zero is only=
=20
guaranteed good at the time of shipping and can go bad with time.  Also,=20
many/most systems use block zero for some other purpose (eg. boot data or=
 bad=20
block marker). Thus, relying on chunk zero being good is pointless.=20

Yaffs needs some chunk/block Id for "does not exist". As I mentioned befo=
re,=20
this could have been 0xFFFFFFFF/-1, but there are places (eg. Tnodes) whe=
re=20
YAFFS uses 16 bit values. Using 0xFFFFFFFF as an invalid marker gets to b=
e a=20
headache when using 16 and 32 bits because we'd have to look at special=20
cases.  Zero is way easier.

Now this mapping stuff could be done in YAFFS so that YAFFS would be able=
 to=20
start at block zero, but this has not yet risen to the top of the importa=
nt=20
things to do pile, mainly because the workaround is trivial (which implie=
s,=20
of course that fixing it in YAFFS is trivial too :-)).


-- CHarles