Re: ancient OS history, ARM is sort of channeling the IBM 360

Lawrence D'Oliveiro wrote:

On Tue, 25 Jun 2024 22:28:40 -0700, Stephen Fuld wrote:
 

But if you are using the "standard" Unix file system, doesn't it
read the block(S) into its cache, then when the user program does
the read, transfer the data from its cache into the user's
variables?  That is the extra overhead to which I was referring.

 
That tends to happen anyway, even on OSes which insist on
record-oriented I/O. For example, on DEC’s VMS, the record blocking
layer is called “RMS” (“Record Management Services”), and that
usually copies records between the user’s buffers and its own
internal buffers (“move mode”). It is possible to request “locate
mode”, where it returns the address of a record directly within its
internal buffers. But there are many restrictions on this, among
other things:
 
* It only works for reads, not for writes
* It doesn’t work for records crossing block boundaries
* It doesn’t work for compressed records
 
So this record-copying overhead is not, in itself, a point against
Unix- style streaming I/O.

The fact that other OSs "made the same mistake"  :-) isn't a point for
treating all I/O as a stream of bytes.  I don't know VAX, but I don't
understand why not for writes.  The no crossing block boundries is a
side effect of fixed block disks.  This couldn't happen in OS/360 with
CKD disks.  I agree about compression, of course, as unless you do the
compression in the I/O hardware stream, you need to "move" the data
anyway.




--
 - Stephen Fuld
(e-mail address disguised to prevent spam)