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

Re: node types etc.




prumpf@xxxxxxx.uk said:
>  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 
same time)

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.


prumpf@xxxxxxx.uk said:
>  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 :)


prumpf@xxxxxxx.uk said:
>  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?

--
dwmw2



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