Hi all

Last night (my time) I checked in code to do the so-called "checkpointing" for 
YAFFS2. This stores away information in NAND which can be read quickly to 
reconstitute a file system without having to scan the whole NAND array. 
Result:way faster mount times.

I've been testing this on a Linux ARM board with 128MB of 2kpage NAND. Boot 
time for partition loaded with 2000 files each holding 50kbytes of data (ie 
100MB in use) is around 0.22 seconds. Which is between 15 and 20 times as 
fast as it was with only the lazy loading.

================ snippet from log ==============
sh-2.05a# time umount yaffs

real    0m0.080s
user    0m0.010s
sys     0m0.020s
sh-2.05a# time mount -t yaffs2 /dev/mtdblock/1 yaffs
yaffs: dev is 7937 name is "1f:01"
yaffs: Attempting MTD mount on 31.1, "1f:01"
checkpt blocks 0 20 21 999
checkpoint byte count 224532
yaffs: restored from checkpoint

real    0m0.240s
user    0m0.010s
sys     0m0.200s
sh-2.05a# df yaffs
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock/1         125312    104812     20500  84% /mnt/yaffs
================== end snippet ===================

The code has been checked in to CVS, but the kernel makefile has not been 
updated yet because I'm currently using a hacked build. Easy to do yourself 
though: add yaffs_checkptrw.c and yaffs_nand.c to your build.

There is one twist: The checkpoint data is invalidated by any writes to the 
partition. At present, a clean unmount will refresh the checkpoint data. This 
only takes approx 0.2 seconds.

Tuning: 

The checkpoint data is saved in NAND blocks in a region specified by
dev->checkpointStartBlock to dev->checkpointEndBlock.  From yaffs_fs.c
               dev->checkpointStartBlock = 0;
                dev->checkpointEndBlock = 20;
                dev->startBlock = dev->checkpointEndBlock + 1;
                dev->endBlock = nBlocks - 1;

You can defeat the checkpointing by setting the checkpoint and main areas to 
overlap. eg:
               dev->checkpointStartBlock = 0;
                dev->checkpointEndBlock = 0;
                dev->startBlock = 0;
                dev->endBlock = nBlocks - 1;

So how many blocks doyou need to store checkpoint data? I'll add this detail 
some time... but for playing around a start number of 20 or so should be fine 
for a 128MB partition. The checkpointing data for the situation mentioned 
above only needs 225kB of data (~2 blocks) + a few more for bad blocks....

-- Charles