[Info-vax] New filesystem mentioned

[Bob Gezelter]

On Wednesday, May 15, 2019 at 3:42:13 AM UTC-4, Chris Scheers wrote:
> Dave Froble wrote:
> > On 5/14/2019 4:52 PM, Chris Scheers wrote:
> >> Bob Koehler wrote:
> >>> In article <qbco24$r22$2 at dont-email.me>, Dave Froble
> >>> <davef at tsoft-inc.com> writes:
> >>>> Not that I'm an expert on VMS clusters, but it has been my impression
> >>>> that the OS did all the work.  But what do I know?
> >>>
> >>>    The file system is very much part of the OS.  If it's going to work
> >>>    in VMSclusters, it must support VMSclusters.
> >>
> >> There seems to be some heavily blinkered, all-or-nothing thought going
> >> on in this discussion.
> >>
> >> There were file systems in VMS before clusters and those file systems
> >> still work.
> >>
> >> For example, it should be possible to side step the DLM by doing a
> >> local, ACP based file system and MSCP serving the results to the cluster.
> > 
> > This really isn't about the DLM.  It's more about coordination.  The DLM 
> > is a tool that can be useful for that.
> > 
> > Even a file system running on one node still needs some type of locking.
> > 
> >> Obviously, this looses the advantages of being cluster aware, but it
> >> does provide the advantages of the file system without needing to go
> >> down the DLM rabbit hole.
> > 
> > What would such a filesystem be used for, without some form of locking 
> > available?
> > 
> >> So the real question is: What are the advantages of being cluster aware
> >> vs. the advantages of the file system?
> >>
> >> Having both is best, but is there a viable compromise that is useful?
> >>
> >> I think that being useful, even with limitations, is a whole lot better
> >> than having nothing.
> > 
> > 
> > The real rabbit hole is caching.  Let me tell you, if you're using 
> > caching, you will not give it up.  Even on a single system the 
> > difference with caching on or off is like night and day.
> > 
> > And the coordination of not just what's "on disk" but also what's in the 
> > cache(s) can be rather non-trival.  It scared us when we looked at it. 
> > It's even complex on a single system.
> 
> That's the point of an ACP.  (And the problem with an ACP.)  All I/O for 
> all users goes through a single process.  There is no need for the DLM.
> 
> The ACP is responsible for its caching.  The ACP is a weird mixture of 
> process context and device driver context.  It has access to the various 
> synchronization mechanisms available to both processes and drivers.  It 
> can use the DLM, but it does not have to.
> 
> -- 
> -----------------------------------------------------------------------
> Chris Scheers, Applied Synergy, Inc.
> 
> Voice: 817-237-3360            Internet: chris at applied-synergy.com
>    Fax: 817-237-3074

Chris,

With all due respect, I do not agree with this characterization of an ACP.

An ACP does not do away with the need for a DLM. An OpenVMScluster running shared volumes requires DLM functionality, as there is more than one ACP per volume accessing the on-disk file structure data structures. Orthogonally, the DLM is used for coordinating RMS-level intra-file activity. 

The bright-line difference between an ACP and the FILES-11 Level 2/5 XQP is that the XQP operates at inner-mode(s) within the requesting process rather than a separate process as is the case with the XQP.

The implementation of the file system auxiliary processing as either intra-driver, ACP, or XQP is transparent to the user. The actual interface provided by an ACP/XQP is described in the OpenVMS IO User's Manual.

Could a linux-style VFS-like library be implemented on OpenVMS? Could such a library framework be implemented as an XQP? Likely the answer to both questions is "Yes". As usual, the devil is in the details.

An ACP process failing is bad, but does not always lead to a kernel fault. An XQP-like component, operating in kernel mode, will almost always cause a crash. Which is better? Mileage varies. Depends. 

- Bob Gezelter, http://www.rlgsc.com