Re: [Yaffs] Checkpointing question.

On Tuesday 27 March 2007 02:54, Robin Iddon wrote:
> Hi,
>
> We have recently ported Yaffs to a ATMEL AT91SAM9261EK using a Samsung
> K9F2G08U0M 2Gbit NAND FLASH device.
>
> We're running C straight on the processor for this application, so no
> O/S to speak of.
>
> We have provided the various routines YAFFS needs to run on this
> platform and it does appear to be working, so thanks!

This can be rather deceptive. Stuff that is almost working can often appear to
be working when in fact there are still things broken.

>
> However, I have one question about checkpointing - I cannot decide if
> it's working properly or not. If you look at the output below you'll
> see there's a "bad sequence" error I am concerned with, and also I
> wanted to understand if the initial scan (and resulting
> "isCheckpointed:0") is correct?

The "checkpointing" only works after a checkpoint set has been written (ie.
the fs was cleanly unmounted). If not, then the flash has to be scanned from
scratch.

If the sequence below was after a clean unmount then the checkpointing is not
working.

You should see something like:
starting without a good checkpoint set (due to reboot before umount or first
use)
- mount -> isCheckpointed=0 (there was none), needs to scan
- do stuff
- umount -> isCheckpointed=1
- mount -> isCheckpointed=1 (there was one). No need to scan
- do stuff
- crash/reboot (ie. no umount)
- mount ->isCheckpointed=0 (none), need to scan.
...

Now if you don't umount, you will not lose data (that is the whole point of a
log structured fs), but the checkpoint will be invalid so yaffs will need to
scan from scratch.

I suggest that since you're seeing invalid block sequence numbers, that the
most likely thing that is happening here is that somehow the tags area is
getting screwed up. I suggest you double-check your byte assignment/writing
in the tags area.

>
> Our test consists of Startup/mount/open/read+write/close/unmount and
> these all work (i.e. data is saved/read and no error returns). In this
> case we're just writing 10 bytes to a single test file in the first run
> and reading them back in the second and nothing else; we started with an
> otherwise erased FLASH device (excepting for the pre-marked bad blocks).
>
> Looking at the debugging output we see at startup/mount (extra comments
> in <>):
>
We're starting a mount...
> yaffs: yaffs_GutsInitialise()restore entry: isCheckpointed 0
> find next checkpt block: start: blocks 0 next 1
> find next checkpt block: search: block 1 oid 261 seq 4112 eccr 3
> find next checkpt block: search: block 2 oid 261 seq 4112 eccr 3
> find next checkpt block: search: block 3 oid 4 seq 0 eccr 3
Block 3 (actually physical block 2) has an oid of 4 with seq of 0. That is
probably the checkpoint block, but with the tags screwed up.

> find next checkpt block: search: block 4 oid 0 seq 0 eccr 0
> find next checkpt block: search: block 5 oid 0 seq 0 eccr 0
> <repeats until last block ...>
> find next checkpt block: search: block 2046 oid 0 seq 0 eccr 0
> find next checkpt block: search: block 2047 oid 0 seq 0 eccr 0
> found no more checkpt blocks
> checkpoint byte count 0
> <should this be 0?>
> restore exit: isCheckpointed 0

This says that no checkpoint data was found. If there had been checkpoint data
then isCheckpointed would be 1 and the count > 0.

There was no useful checkpoint so we're doing a scan...
> yaffs_ScanBackwards starts intstartblk 1 intendblk 2047...
> <Yikes - do we expect this bad sequence?>
> Block scanning block 3 has bad sequence number 0
Sequence number of 0 is not valid. Valid sequence numbers start at 4096 and
increment by 1 for every block written.

> <We do expect these 5 blocks to be bad, so that's OK>
> block 127 is bad
> block 840 is bad
> block 1084 is bad
> block 1706 is bad
> block 1975 is bad
> 2 blocks to be sorted...
> ...done Allocating from 2 63
> Allocating from 2 62
> Allocating from 2 61
> Allocating from 2 60
> <snip>
> Allocating from 1 5
> Allocating from 1 4
> Allocating from 1 3
> Allocating from 1 2
> yaffs_ScanBackwards endsyaffs: yaffs_GutsInitialise() done.
>
> Then we read from our test file (which was already written on a previous
> run of the program) and get the correct data.
>
> Then we unmount and get this:
>
> yaffs block 1 gc prioritised
> yaffs block 2 gc prioritised
> save entry: isCheckpointed 0
> checkpt blocks available = 2034
> checking blocks 1 to 2047
> allocating checkpt block: erased 2039 reserved 5 avail 2034 next 1
> allocating checkpt block 4
> checkpoint wite buffer nand 256(4:0) objid 5 chId 1
> checkpoint wite buffer nand 257(4:1) objid 5 chId 2
> checkpoint wite buffer nand 258(4:2) objid 5 chId 3
> checkpoint wite buffer nand 259(4:3) objid 5 chId 4
> checkpoint wite buffer nand 260(4:4) objid 5 chId 5
> checkpoint wite buffer nand 261(4:5) objid 5 chId 6
> checkpoint wite buffer nand 262(4:6) objid 5 chId 7
> checkpoint wite buffer nand 263(4:7) objid 5 chId 8
> checkpoint wite buffer nand 264(4:8) objid 5 chId 9
> checkpoint wite buffer nand 265(4:9) objid 5 chId 10
> checkpoint wite buffer nand 266(4:10) objid 5 chId 11
> checkpoint wite buffer nand 267(4:11) objid 5 chId 12
> checkpoint wite buffer nand 268(4:12) objid 5 chId 13
> checkpoint wite buffer nand 269(4:13) objid 5 chId 14
> checkpoint wite buffer nand 270(4:14) objid 5 chId 15
> checkpoint wite buffer nand 271(4:15) objid 5 chId 16
> Checkpoint write object 1 parent 0 type 3 chunk 0 obj addr 23FE23D8
> Checkpoint write object 2 parent 1 type 3 chunk 0 obj addr 23FE2454
> Checkpoint write object 3 parent 0 type 3 chunk 0 obj addr 23FE22E0
> Checkpoint write object 4 parent 0 type 3 chunk 0 obj addr 23FE235C
> Checkpoint write object 261 parent 1 type 1 chunk 128 obj addr 23FE24D0
> checkpoint wite buffer nand 272(4:16) objid 5 chId 17
> checkpoint byte count 33036
> save exit: isCheckpointed 1

That looks good.

Now what happens if you mount again?

-- Charles