Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!apollo!apollo.hp.com!mishkin
From: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: File sharing across machines?
Message-ID: <1991Mar1.153324@apollo.HP.COM>
Date: 1 Mar 91 20:33:00 GMT
References: <1991Feb23.015726.8621@intek01.uucp> <50164f63.20b6d@apollo.HP.COM>
Sender: root@apollo.HP.COM
Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Organization: Hewlett-Packard Company - Cooperative Object Computing Operation
Lines: 54

In article <50164f63.20b6d@apollo.HP.COM>, pcc@apollo.HP.COM (Peter Craine) writes:
>In article <1991Feb23.015726.8621@intek01.uucp>, mark@intek01.uucp (Mark
>McWiggins) writes:
>|> We're porting a C-tree multiuser application to the Apollo.  C-tree opens
>|> files in O_RDWR mode.  This works fine for multiple processes on a single
>|> machine, but the same process on another machine fails to open the file
>|> with "Text file busy".
>
>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.
>
>"But why can it work in NFS, but not in Domain?"
>
>NFS is implemented in a client/server model [no kidding].  So, when a computer
>accesses a file, it is really asking a daemon on the computer where the file
>lives to access the file. ...
>
>Not so with Domain.  (Here we go again).  Domain/OS is a "single-level store"
>Operating System. ...

This is really not an accurate picture of what's going on or what the
problems are.  First off, DOMAIN accesses to remote files are done via
a client/server model as well.  (The server is what some of the funny
processes listed by "/com/pst -l1" are.)  The server is sent requests
to read and write blocks of a file, just like NFS.  The only significant
differences between the NFS server and the one in DOMAIN is that the
former uses a publicly specified protocol (good idea!) and the latter
embodies and enforces certain rules about concurrent access to files
(also a good idea, as far as I'm concerned).  It is this second difference
(and not that the DOMAIN stream I/O layer is built on top of a mapped
file layer, which, as it happens, is SunOS's these days) that is the
reason you can't have multiple, non-colocated writers of the same file.

Note that having multiple, non-colocated writers of a file doesn't work
in general with NFS either.  The results of having multiple such writers
is not deterministic and you're not guaranteed to see the same behavior
(or ANY particular well-defined behavior) as you would if the files had
been written and read locally.  Yes, it works for some applications
(especially if you happen to know the details about how the NFS protocol
is typically IMPLEMENTED, as opposed to SPECIFIED) and, yes, maybe DOMAIN
should offer the ability to let people get non-deterministic behavior;
after all, it's their nickel.  It just so happens that it doesn't.

BTW, the OSF DCE Distributed File System, which is based on the CMU ITC
Andrew File System, DOES support multiple, non-colocated writers and
it does it right.  It has a scheme for passing logical "tokens" around
among the various network clients accessing a file.

--
                    -- Nat Mishkin
                       Cooperative Object Computing Division / East
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com