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

Re: node types etc.

On Tue, Jan 16, 2001 at 09:11:58AM +0000, David Woodhouse wrote:
> 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
> immediately.

I can imagine other types of extra data that would have to be invalidated
immediately, depending on how you design them.  CRTs for file data would be
one example.

> My idea for the checkpoint reading was...

sounds correct.

> 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.

checkpoints might be the common case, but their requirements are not those
of the general case.  I think replacing _DELETE in the name with _CHECKPOINT
would make sense (if you really want checkpoint node semantics you get them,
otherwise you have to choose between copy and rw incompatibility).

> 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 
> so.


> 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.

shared compression state (huffman tables, dictionaries).  shared encryption
state, too [*] (adopting CSS-like crypto to jffs wouldn't be too hard with

[*] note to US readers: I didn't say this, unless your laws have been fixed
by now.

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