After much consideration and thought, I have taken your advise and removed the option of multiple text encodings. UTF-8 is now specified for all text strings.

May I quote something I saw over on hackaday.org today:

Thank you all for your comments. The new specs are up, with an addition. This addition makes all aspects of the volume have a checksum (when extended checksums are used). The Superblock, Inodes, Indirects, Extents, and now the bitmap.

You'd also need this for the data checksum for the per-extent checksums.

The spec doesn't indicate how the block bitmap checksum is calculated.

It can't use the existing checksum definition, because:

[*] The existing checksum reserves the first uint32_t for the checksum itself, and so doesn't include it in the checksum.
[*] The existing checksum is for a contiguous data structure, and the bitmap is not contiguous.

With that in mind, perhaps it's worth redefining the checksum procedure, so that:

[*] All the passed in data is included in the checksum, not skipping the first field (this skipping would have to be done by the caller if required.)
[*] Pass in a partial checksum, that will be used instead of 0 at the start.

With the above, we can run the checksum against each bitmap in turn, keeping track of the partial checksum on the way, and putting the final checksum in the superblock.

You'd also need this for the data checksum for the per-extent checksums.

Actually, I'm not sure this checksumming of extent data would work practically.

Consider, creating a large file. You know how big it is going to be, so you can reserve all the space up front, and the leanfs driver might find and assign a single extent to it.

You now have to checksum that whole file in one go.

Worse, when you come to read it in later, you have to load the entire extent into memory to checksum it, before it can be passed back to the user buffer. You can perhaps stream it to limit the amount of memory in use doing it, but you will still have to load all the data.