This book I’m looking at on filesystem design mentions the paper by
McKusick, Joy, Leffler and Fabry in the August 1984 “Communications of the
ACM” on the Berkeley Fast File System (FFS, later became more widely
popular as UFS).

This was a breakthrough, at least in the Unix world at the time, because
the previous filesystem could only make use of 3-5% of the available disk
bandwidth, while FFS took this to more like 47%.

Back then, other OSes (like VMS) did not try to hide from applications the
fact that file space allocations were done in units of sectors (or some
multiple thereof). Whereas Unix pioneered the idea that, if an application
wrote 975 bytes to a file, then it will only read back 975 bytes, not 1024
bytes (or some even larger amount).

Were these other non-Unix OSes making more efficient use of disk I/O
bandwidth than Unix, at the time? Was the abstraction away from whole
sectors/clusters really that costly, at least to begin with?

On 1/14/2024 7:10 PM, Lawrence D'Oliveiro wrote:
> Back then, other OSes (like VMS) did not try to hide from applications the
> fact that file space allocations were done in units of sectors (or some
> multiple thereof). Whereas Unix pioneered the idea that, if an application
> wrote 975 bytes to a file, then it will only read back 975 bytes, not 1024
> bytes (or some even larger amount).

If the VMS application use language RTL IO or RMS then then it
also write N bytes and read N bytes.

(there is a small difference in that the number of bytes on
disk may be different from N depending on API and the
record format of the file!)

It is only if using SYS$QIO(W) or SYS$IO_PERFORM(W) to do IO
that the view of the file becomes X allocated blocks where the code
needs to deal with FAT$L_EFBLK and FAT$W_FFBYTE. And explicit
extend file when needed.

Arne

On 1/14/2024 7:22 PM, Arne Vajhøj wrote:
> On 1/14/2024 7:10 PM, Lawrence D'Oliveiro wrote:
>> Back then, other OSes (like VMS) did not try to hide from applications
>> the
>> fact that file space allocations were done in units of sectors (or some
>> multiple thereof). Whereas Unix pioneered the idea that, if an
>> application
>> wrote 975 bytes to a file, then it will only read back 975 bytes, not
>> 1024
>> bytes (or some even larger amount).
>
> If the VMS application use language RTL IO or RMS then then it
> also write N bytes and read N bytes.
>
> (there is a small difference in that the number of bytes on
> disk may be different from N depending on API and the
> record format of the file!)
>
> It is only if using SYS$QIO(W) or SYS$IO_PERFORM(W) to do IO
> that the view of the file becomes X allocated blocks where the code
> needs to deal with FAT$L_EFBLK and FAT$W_FFBYTE. And explicit
> extend file when needed.

To clarify. Applications do not *need* to know or deal with
it, but they still *can* if they want to.

Heck - even DCL can.

scare.com:

$ set ver
$ type 'p1'
$ eof = f$file(p1, "eof")
$ ffb = f$file(p1, "ffb")
$ set file/attr=(ebk=0,ffb=0) 'p1'
$ type 'p1'
$ set file/attr=(ebk='eof',ffb='ffb') 'p1'
$ type 'p1'
$ exit

and:

$ @scare something.ext

:-)

Arne