VMS vs. UNIX file system

[Guy Harris]

> I think a more fundamental advantage of the VMS I/O system is that
> QIO's can be queued to execute asynchronously (similarly for RMS
> operations).

This is orthogonal to the issue of the VMS file system vs. the UNIX file
system.  You could have a VMS-style file system, RMS and all, atop a UNIX-style
I/O subsystem (imagine implementing RMS atop "read" and "write", with RMS doing
no read-ahead nor write-behind, but leaving it up to the "read" and "write"
code to do so), and you could have a UNIX-style file system, wherein the file
system things of files merely as collections of bytes, atop a VMS-style I/O
subsystem (imagine VMS with QIOs to open/read/write/close/etc. files being the
published fundamental I/O operations, and with "read" and "write" perhaps
implemented as library routines atop this).

I suspect you may see various flavors of asynchronous I/O on files supported
various versions of UNIX in the future.  ("Asynchronous I/O" means
"asynchronous" in the VMS sense - e.g., "aread" and "awrite" calls that do not
block until completion, and an "iowait" call to wait for one or more such calls
to complete - not "asynchronous" in the 4.[23]BSD sense, where the ability to
do some amount of I/O without blocking can be signalled for certain objects by
sending a SIGIO to interested processes.)  I think HP may already have this.

> On Unix, you can get asynchronous I/O by going through the buffer
> cache, but this doesn't provide a clean way for the error status to be
> returned (for example, NFS writes that go over quota can appear to
> complete, but return the error later, when performing another
> operation),

"fsync" provides this to some degree; NFS implementations tend to provide such
write-behind errors to the caller of "fsync", but I don't know if they also
provide write-behind errors for local file systems, e.g. an attempt to push a
buffer to disk getting a physical I/O error.