[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: checkpointing




bjorn.wesen@xxxxxxx.com said:
>  The layout of the checkpoint structure is another question though. It
> needs to be checksummed just like normal jffs nodes, and contain all
> the information necessary for the in-core rep of the logical flash up
> to that point. 

It would be best to keep the checkpoint as small as possible. You rebuild
the in-core representation slowly (possibly in the background), but you just
have enough information in the checkpoint to allow you to quickly satisfy
read requests without having to scan the entire flash.

How about either:

1. A set of {inode,highest_version} tuples.

 To satisfy a read request, you still have to scan the flash until you've 
 found the highest version (and also scan any blocks written _after_ the 
 checkpoint of course), but it does mean that you no longer have to 
 scan the _entire_ flash to satisfy a read request. At least, not in
 all cases. Worst case, you still do.

2. A set of {inode,version,location} tuples. 

 This allows you to quickly perform read requests - and shouldn't be _too_ 
 large - 12 bytes per node on the filesystem. Of course you still need to 
 scan the blocks which postdate the checkpoint, but other than that, you 
 have enough information to go straight to the data which are requested. 

(actually, if we don't have many deleted inodes, it might be better not to
store the inode# in either of the above, just have an array indexed by inum).


Thinks... to speed up the process of finding a file by name, p'raps we want
to store &name, and/or parent information too.

--
dwmw2