[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> 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.
Definitely. On mount, you look at the first node in each sector, if any.
Only if it's newer than the last checkpoint you find do you need to scan
that sector completely. (Obviously you scan the remainder of the node that
_starts_ with the newest checkpoint, too.)
> 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.
You can do this asynchronously, before moving the block from the 'erased'
list to the 'next to write' slot. If you have the slack space to do it
without breaking the GC.
> 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 hints :)
Heh, well shall we hardcode the length to __u16 to make sure it stays
> 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
> That's quite a rewrite of JFFS though, but it's a roadmap at least :)
That's OK, because I believe it doesn't require any incompatible changes to
the storage format (although we should probably put together a slightly
more detail proof-of-concept to check that). As long as we don't change the
storage format, we can rewrite the internals as much as we like.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org