Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: VMS vs. UNIX file system Message-ID: <69309@sun.uucp> Date: 21 Sep 88 05:14:06 GMT References: <411@marob.MASA.COM> <3597@encore.UUCP> <3438@crash.cts.com> <10105@eddie.MIT.EDU> Sender: news@sun.uucp Lines: 32 > 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.