1. Forum
  2. Usenet
  3. COMP.OS.VMS

  • File I/O BandWidth Versus Disk I/O Bandwidth

    From Lawrence D'Oliveiro@21:1/5 to All on Mon Jan 15 00:10:52 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Sun Jan 14 19:22:54 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Sun Jan 14 19:35:46 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)