Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Ckparity is pretty flawed in littlefs, for several reasons. The biggest one being that we can't even reliably detect single-bit errors. But! It can still provide an extra layer of safety in a system where you don't care about the extra code/stack cost. And, for ckreads, performance cost... Performance isn't a big problem for parity-checking. We can assume metadata tags are going to relatively small (and can be controlled by fragment_size). But for data checksums, ckreads risks O(b^2) when performing many small reads, which can be a bit of a problem. And since ckreads doesn't really prove anything interesting about the system anymore, it makes sense to unbundle these two checks, rename ckreads -> ckparity, and limit it to only checking parity bits. This way, you can enable ckparity for a bit of extra safety, with a code/stack cost hit, but without sacrificing performance. --- I was hoping more code/stack savings, but since we still need to track parity context in lfsr_data_t, and still need to intercept bd_read/cmp/ cpy calls that reference metadata, we end up needing to keep most of the ck circuitry around: code stack default before: 36464 2672 default after: 36464 (+0.0%) 2672 (+0.0%) code stack ckparity before: 38036 3080 ckparity after: 38024 (-0.0%) 3080 (+0.0%) We even end up still tracking checksum context for bptrs! Maybe we should just go ahead and add ckcksums as a joke...
- Loading branch information