that makes sense; i had seen forth printed that way but had forgotten about it. i think the code was printed side by side with the shadow screens (the comments), requiring 132 columns (4 of padding i suppose)

i think that, if you want to put the metadata into multiple blocks, you need to have some control over the order of buffer saving. one way to do this would be to have two copies of the metadata that you alternate between, which would be desirable anyway in case of power loss during metadata writes. maybe once every 30 seconds, say. after your last modification to replica tweedledee and before your first modification to replica tweedledum, you would call save-buffers, ensuring that briefly tweedledee is also consistent on disk (tweedledum already having been consistent), even if buffer evictions later put tweedledee into a torn state

then the question is how, upon startup, to know whether to use tweedledee or tweedledum? maybe an update serial number at the beginning and end of the block that has to match?

using a cluster size larger than the forth block size seems like it might complicate the calling interface somewhat

glad to hear from you!