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

Re: node types etc.

prumpf@xxxxxxx.uk said:
> > /* RWCOMPAT_DELETE: Mount read/write, and delete the node when it's GC'd */

> I'm not sure when this type would ever make sense.  I think
> /* RWCOMPAT_DELETE: Mount read/write, and make sure this node is deleted */
> would make sense, but it requires a forced gc pass on mount. 

This is going to be used fairly soon, for checkpoint nodes. The checkpoint
reading code always needs to be able to detect whether the checkpoint it's
looking at is (partially) obsoleted by later writes and do the manual scan
on any blocks which were written later. So there's no need for us to insist
on the checkpoint-incapable code deleting any existing checkpoint nodes

My idea for the checkpoint reading was...

 1. Scan the flash, looking at the beginning of every erase block for 
	a checkpoint node. Note the most recent one and 'eat' its state
 2. Scan the flash, looking for the timestamp of the first node in each
	erase block. 
 3. For each block you find which is not older than the checkpoint 
	(including erased blocks):
		- Remove all nodes from your state snapshot which are
			in this block - if there were any, it's because
			this block has been deleted and reused since the
		- Manually scan the eraseblock and add the nodes therein to
			your list.

(See yesterdays meanderings for the suggested form of the checkpoint - just 
lists of {ino,flashoffset} pairs. I don't think we need to store the 
'obsoleted' part, at least not on the flash)

We can write out a checkpoint whenever we like. Based on how much slack 
free space we have, how long it's been since the last one, how idle the 
system is, etc. We never have to make sure that the previous one is deleted 
before writing a new one.

When we GC a checkpoint node, we can just delete it, because it's almost 
certainly obsolete. And it's fine for the older code to do that too - just 
delete it when it gets round to it, but not to make a special effort to do 

It's actually the RWCOMPAT_COPY one I wasn't sure we'd need - but it may 
turn out useful for something like permanent storage of per-filesystem 
options, which older code could ignore but we'd prefer it stays in the 
filesystem for the later code to obey.


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com