[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:
> email@example.com said:
> > > /* RWCOMPAT_DELETE: Mount read/write, and delete the node when it's GC'd */
> > > #define CJFFS_FEATURE_RWCOMPAT_DELETE 0x0000
> > 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
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
> My idea for the checkpoint reading was...
> 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
> 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
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org