[Yaffs] Checkpointing... big mount speed up

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: yaffs
Subject: [Yaffs] Checkpointing... big mount speed up
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