On 30.09.2017 19:28, Peter Stuge wrote:
Nico Huber wrote:
We already have a simple coreboot-native key-value store: CBFS
Well, I had a look at it now. And indeed it is a coreboot-native key- value store and could be used in the same way I imagined my proposed storage format. But it's not simple.
Well, I never looked close, but everybody kept telling me for years that CBFS is not designed for updates.
But it is!?
Could be.
Not in-place updates, because CBFS isn't tied to eraseblock sizes, but a CBFS entry could be overwritten with 0x00, which makes readers scan for the next entry.
We have CBFS_COMPONENT_DELETED (0) type. It basically already works like that.
If we haven't already we can declare entries with zero length names as deleted. Then the length remains, and no scan is neccessary. That would keep optimal read speed.
You are implying that read speed is already optimal?
What is really bothering me is that CBFS does two layers at once (key- value store and attribution), and it has to for its current purpose: CBFS can be sparse and has to be to allow entries at specific offsets or with specific alignment. We probably don't want to mix that with erasures. So I suppose we would want another FMAP entry for the era- sable key-value store anyway and its unlikely that we'd need any of the fancy CBFS features there. But if we account for full CBFS com- patibility in the defragmentation scheme (or whatever we'll call it), I fear, things will get way more complex then they need to be.
Nico