Subject: synchronous nature of modifying operations

From: Spencer Shepler <[email-masked]>
Date: Thu, 03 Feb 2000 15:35:52 -0600

The NFSv4 I-D is missing a statement about the requirement
that operations that modify the file system must be
written to stable storage (except for those that explicitly
state otherwise -- unstable WRITEs).  Therefore, I will be
adding the following statement to section 13.

--
Synchronous Modifying Operations

NFS version 4 operations that modify the file system are synchronous.
When an operation is successfully completed at the server and the
response returned to the client, the client can depend that any data
associated with the request is now on stable storage.
--

There are many uses of 'stable storage' throughout the I-D
and it is not defined as it has been in the NFSv3 specification.
Therefore, a definition needs to be added to the General Definitions
section.  Taken from the NFSv3 specification, I propose the following
be added:

--
Stable storage

NFS version 4 servers must be able to recover without data loss from
multiple power failures (including cascading power failures, that is,
several power failures in quick succession), operating system
failures, and hardware failure of components other than the storage
medium itself (for example, disk, nonvolatile RAM).

Some examples of stable storage that are allowable for an NFS
server include:

1. Media commit of data, that is, the modified data has
   been successfully written to the disk media, for example,
   the disk platter.

2. An immediate reply disk drive with battery-backed
   on-drive intermediate storage or uninterruptible power
   system (UPS).

3. Server commit of data with battery-backed intermediate
   storage and recovery software.

4. Cache commit with uninterruptible power system (UPS) and
   recovery software.

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 4 Feb 2000 11:57:12 -0800

> > In the event that a response to a compound request is not 
> returned to
> > the client but some or all of the operations were successfully
> > executed, the server may choose to reflect some or all of those
> > executed operations in stable storage.  However, if the server
> > reflects the results of an operation in stable storage, all previous
> > operations contained within the compound request must be represented
> > in stable storage as well.  For example, if a compound request
> > contains operations A and B and the server does not send a 
> response to
> > the client, the result of both operations may be reflected in stable
> > storage or just operation A may be reflected.  The server must not
> > have just the results of operation B in stable storage.
> 
> Why does the specification need to say anything about results 
> the server
> hasn't sent back to the client?
> 

The client is going to try to recover (after a server reboot, for
example) and is going to try to figure out what happened.  If he
knows that the operations completed and reflected to stable storage
are an initial subset of the request, then he has an easier job.
It is very difficult if any subset of the ops for a request may
appear to have been done as reflected on stable storage.