Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!umich!terminator!pisa.citi.umich.edu!rees
From: rees@pisa.citi.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: File sharing across machines?
Message-ID: <502119bb.1bc5b@pisa.citi.umich.edu>
Date: 2 Mar 91 20:36:17 GMT
References: <1991Feb23.015726.8621@intek01.uucp> <50164f63.20b6d@apollo.HP.COM>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan ITD
Lines: 32

In article <50164f63.20b6d@apollo.HP.COM>, pcc@apollo.HP.COM (Peter Craine) writes:

  I'm afraid that I've got some bad news for you.  Once you open a file for write
  access on a node, the node that performs the "open" is the ONLY node that will
  be able to access that file...

In any distributed file system that provides both consistency and local
caching (this doesn't include NFS), you need some sort of locking protocol
to mediate access to the central object.  The Domain file system was one of
the first and chose to do this locking at open time.  But this gives you a
file system that doesn't look just like real Unix.  The Domain file system
was actually designed and built before Aegis looked anything like Unix, so
in a way it's a miracle that it does as well as it does at imitating Unix.

In more modern Unix distributed file systems such as AFS, locking is done at
a much finer temporal resolution, usually at the individual read/write time.
This makes reading and writing slower, but makes the distributed system
look more like the central system that you're used to.  In most cases this
penalty is negligible, because the normal case doesn't include multiple
writers on different clients.

In principle, you could write an ios type manager that used the single-level
store to access file system objects, but put an extra locking layer on top
to do the locking at read/write time, and make the file system appear like a
central Unix file system (modulo performance).  You could even do it as a
pass-through (Apollo-speak for type inheritance) of the unstruct manager.
The open operation would open for inq-only.  Read and write would re-lock
for read/write, do the io, then unlock.  Other operations would simply
pass-through to unstruct.

This wouldn't be hard.  Since I'm already using AFS, I'm not going to
bother.