Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.unix-wizards
Subject: Re: Extended file system on UNIX 4.2/4.3 BSD
Message-ID: <1011@brl-tgr.ARPA>
Date: Mon, 23-Dec-85 19:00:23 EST
Article-I.D.: brl-tgr.1011
Posted: Mon Dec 23 19:00:23 1985
Date-Received: Thu, 26-Dec-85 04:13:32 EST
References: <910@brl-tgr.ARPA> <2adcce15.1de6@apollo.uucp>
Organization: Ballistic Research Lab
Lines: 16

> ATT/RFS implements unix file system semantics exactly at the expense of not
> being stateless and not caching data in the client.  NFS has a stateless
> server at the expense of unix file system semantics.  In case it isn't
> obvious, the big advantage of a stateless server is that it simplifies
> recovery after machine or network failure.

AT&T's RFS, I was told, treats a network link going down the same
as it would a disk going off-line; there will be an error returned
from any subsequent attempt to do I/O to the inaccessible file.

Note that full support for UNIX file system semantics is a crucial
issue for AT&T UNIX System V systems, which support record locking.

The obvious alternative to I/O errors when a net link goes down is
to block processes doing remote file I/O over the link until it
comes back up; this is probably unwise for record locking systems.