[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Thu, 11 Jan 2001, David Woodhouse wrote:
> Checkpointing will remove the need to scan the whole flash. But even with
> separate dirents, you'll have to scan the whole flash to make sure you've
> found them all before you can do anything useful.
I was thinking of making rules like checkpoints can only be written at
aligned places, for example in the beginning of a sector. Then you can
find the last checkpoint very quickly.
That should not pose a problem because a checkpoint is not something which
VFS or the user wants to write synchronously, it's something JFFS decides
to write when certain heuristics are met. Missing a checkpoint write is
not fatal either, it just means the next scan needs to scan a bit more
manually after the last checkpoint.
> For now, I'm not going to get involved in the checkpointing. It may be useful
> at this stage to define the first few bytes of a checkpoint node as
> __u32 magic
> __u32 nodetype /* Or whatever magic/nodetype setup we decide on */
> __u16 length
> ... so the current code can at least know how to skip over it, so that
> it'll be able to read filesystems created later on when we've implemented
> Is 64KiB large enough for the checkpoint node?
I'm worried that the checkpoint can get very large if we don't do it very
efficiently. I'll check some of my log-structure filesystem books for
Basically the checkpoint might just be a flattened hierarchy where all
actual data is simply an offset into the flash where the corresponding
jffs node live. The metadata in the checkpoint will correspond to dirents
and lengths of the arrays of jffs node offsets.
root: (directory, offset 1234, num children: 2)
child 1: (num jffs nodes 3) <- identify the child ? how ? inode nbr ?
node 1 (offset 5565) <--- these 3 are the active nodes
node 2 (offset 9239) for the child 1 file, no
node 3 (offset 12032) need to list obsoleted ones
child 2: (directory, offset 2324, num children: 1)
child 1: (num jffs nodes 2)
node 1 (offset 15667)
node 2 (offset 15998)
node 3 (offset 16040)
The decode_checkpoint() routine during scan just reads the checkpoint and
knows directly where in the flash all the live nodes are.
HOWEVER, the big win here is that we can do this (because it's fast to
lookup things now):
* skip the initial scan during boot
* loose the in-core representation
* do the checkpoint decode on-the-fly during dirent/inode lookup
Then VFS in 2.4 will itself handle the caching of the in-core
representation in the dentry and inode caches. If something needs to be
flushed, the subsequent re-read is not painful.
That's quite a rewrite of JFFS though, but it's a roadmap at least :)
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org