[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Tue, 26 Sep 2000, David Woodhouse wrote:
> Too many writes to it. Keep it in a special jffs_node in the main
> filesystem, perhaps. Still have to scan for the latest one, though. Perhaps
> put one _only_ at the beginning of an erase block, nowhere else. Then it's
> quick to find the latest one, and also you know which blocks were written
> _after_ the checkpoint (nodes have mtime).
Yes that makes sense (when you write a checkpoint, you do it aligned in a
way that makes it fast to find the latest sane checkpoint).
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
The checkpoint needs to contain enough data to specify what "up to that
point" really means though. The most sane way of doing this (in light of
that we're going to add random erase-block choice) is to specify which
other erase-blocks "worth of nodes" it contains information about (so we
know when booting which blocks needs to be jffs_scan_flash'ed after the
checkpoint is read and which don't).
It also needs to contain information about the physical extent of the
nodes the in-core points to (the fm stuff) so that the fm list can be
reconstructed from the checkpoint info upon boot.
Perhaps the fm in-core stuff can be changed to be a bitmap of 16 or
32-byte chunks instead (and write that out into the checkpoint) but maybe
that breaks something that needs to know "what nodes are at THIS place in