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 -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
