inode checkpoints

[Artem Bityuckiy]

Hello. We are working on the possibility to increase JFFS2 on NAND 
flashes and want to decrease the iget() call delay. We are going to 
introduce "inode checkpoints" which are special type of nodes. 
Checkpoints are created for the regular file inodes and directory inodes.

Here is the idea description.

-----------------------------------------------------------------------

Currently when JFFS2 builds the inode cache for a regular file (iget() 
call), it performs the following tasks (among others):

1 reads headers of all the file nodes;
2 reads all the file nodes data and checks CRC (if the data CRC wasn~Rt 
yet checked because this activity is only performed once for each file 
until unmount).

If the JFFS2 is used with the NAND flash type, the access to all the 
node headers which are distributed over different NAND flash pages might 
be very expensive (especially if the file is relatively big). It is more 
effective to have all these headers together in one inode checkpoint 
node and to read them all from few pages.

The second task is mainly needed to handle bad nodes and to perform roll 
backs. The roll back means, that if there are bad nodes, JFFS2 discards 
them and uses older ones. Thus, in case of unclean reboots, file data 
which have already been successfully written can not be corrupted by the 
subsequent broken writes. This mechanism doesn't guaranty the roll back 
in case of flash media corruption, just unclean reboots are handled.

Thus, it is important to check file data only once, and if it is OK, it 
isn't necessary to check it anymore. But currently, after every reboot 
all the files are rechecked. But with checkpoints, JFSS2 doesn't need to 
re-check nodes which are referred by the checkpoint, since they have 
already been checked when the checkpoint node was created. Thus, with 
checkpoints, fewer data have to be read and checked. This also decreases 
the iget() call delay.

When JFFS2 builds the inode cache for the directory inodes, it currently 
reads all the direntries, which are located in this directory. This also 
means that in case of directories with lots of direntries, JFFS2 reads 
lots of small direntry nodes from different NAND pages. Having the 
checkpoint for the directory, JFFS2 might read that information from 
much fewer pages.

The drawback of checkpoints is that the additional flash space is used. 
To save more space checkpoints are compressed.

-----------------------------------------------------------------------

Wha do JFFS2 folks think about the idea?

-- 
Best regards, Artem B. Bityuckiy
Oktet Labs (St. Petersburg), Software Engineer.
+78124286709 (office) +79112449030 (mobile)
E-mail: dedekind at oktetlabs.ru, web: http://www.oktetlabs.ru