[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: node types etc.
> 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.
(do you mean CRCs? Those are written with the data and obsoleted at the
It's a log-structured filesystem. I don't think we want to encourage people
to design stuff that has to be overwritten immediately, rather than just
signalling it as obsolete by writing a later node elsewhere. So if you want
RW_DELETE semantics for older code, you arrange it such that later data
writes to the inode will obsolete your node automatically - include a copy
of the current highest version number for that inode or something.
You just can't go back and obliterate an older node on NAND flash. You've
had your ten writes to this page. You try to clear one more bit, and as far
as you're concerned, all subsequent reads from that page can return random
data. Unless you GC that entire block immediately and leave out that node.
Hence JFFS_MARK_OBSOLETE being turned off. It's a nice optimisation where
it's possible. But we must not rely on it. And we mustn't ever rely on
being able to do it.
> 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).
I chose _DELETE because it describes the semantics. _CHECKPOINT just
describes the one use we can think of ATM for those semantics. I prefer the
name _DELETE but when that's the most important thing we've got left to
discuss, I'll be happy :)
> shared compression state (huffman tables, dictionaries). shared
> encryption state, too [*] (adopting CSS-like crypto to jffs wouldn't
> be too hard with this).
hehehe. Sick. But CSS-like crypto for the filesystem would surely be an
INCOMPAT flag, wouldn't it?
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org