3 ms·

In the Forth golden age there was a convention of grouping blocks in triads -- you could print one per page. E.g. when I proposed to rewrite the "full-screen-st

In the Forth golden age there was a convention of grouping blocks in triads -- you could print one per page. E.g. when I proposed to rewrite the "full-screen-style" editor at FORTH, Inc., they were like "if you think you can get it down from 4 blocks to 3, then go ahead" so it wouldn't be wasting 2/3 of a triad. (You might remember this, it was the more-conventional editor they didn't use, contributed by a customer.) So maybe make this filesystem work on triad units: an index fits in a byte, more space for longer filenames. Not sure what to do with the extra block in the filesystem triad.

kragen 3y ago
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!
- abecedarius 3y ago
  Hope you're well! I wasn't proposing keeping file metadata in multiple blocks -- just, might as well consider if any functionality might be worth adding in the remaining block of the filesystem triad, if it's gonna be a triad (source code, metadata, empty). (This makes the larger minimum size of these triads a bit of an attractive nuisance from a "Forth Zen" pov...)
  - kragen 3y ago
    oh, yeah, that makes sense. you could probably fit most of the standard cp/m or unix filesystem utilities into the remainder; cp, rm, mv, cat, head, and so on. maybe nsweep i'm, eh, not dead

kragen 3y ago

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!

abecedarius 3y ago
Hope you're well! I wasn't proposing keeping file metadata in multiple blocks -- just, might as well consider if any functionality might be worth adding in the remaining block of the filesystem triad, if it's gonna be a triad (source code, metadata, empty). (This makes the larger minimum size of these triads a bit of an attractive nuisance from a "Forth Zen" pov...)
- kragen 3y ago
  oh, yeah, that makes sense. you could probably fit most of the standard cp/m or unix filesystem utilities into the remainder; cp, rm, mv, cat, head, and so on. maybe nsweep i'm, eh, not dead