Full Blocks

The trouble with layers and layers of computer software is that sooner or later you lose touch with reality.

Reality. That's what's going on with the physical stuff that makes computers go. CarverMead points out that all computation is a physical process. Why not exploit the myriad effects of ChargeCarriers passing through material, instead of overcoming them?

But I digress. Right now I'm thinking about efficiently transferring information from block storage devices. What in the world is my ThinkPad doing as it sits there blinking my disk light while it boots? A few bytes here, a few bytes there, that's what it's doing. I'd love to put a StripChartRecorder on that light and find out what the real DutyCycle? is. Then again, it probably lights up while it seeks. I'd need to monitor the actual transfer.

Some people seem to understand this and get it right...

• RogerBates -- collected control variables needed to open a drawing.
• BillCroft -- piggybacked control flags in full data packets.
• ParcPlace -- save an image without traversing it.
• JefRaskin -- booted the CanonCat from all sectors of a diskette read sequentially.
  • regardless of whether this means a full track read or a small boot, such things pre-date Jef's work on the CanonCat by years and years; let's not Canonize people for standard practice
• ChuckMoore -- a filesystem abolitionist from the beginning, he strongly prefers to record source code and all persistent data using block storage. Whether using a block cache (a la demand-paging systems today) or full memory image (a la ColorForth today), Chuck gets extremely efficient I/O by eliminating unnecessary filesystem intervention, which from personal experience with both filesystems and direct-access methods, I agree is unnecessary.

Since this page was created June 9 1995 and hasn't significantly changed since then (typos fixed 3 times, is all), I probably shouldn't bother to comment...