Subject: RE: synchronous nature of modifying operations

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 4 Feb 2000 10:05:45 -0800

> 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.

Do we need to say a litle more in the context of COMPOUND?  In 
particular, if operations A and B appear in a single request
(with B following A) and the client has not recieved a response, 
then it is valid for neither, for both, or for just A to be
reflected on stable storage, but it is not valid for just B 
to be reflected 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: Spencer Shepler <[email-masked]>
Date: Fri, 04 Feb 2000 13:29:06 -0600

> to be reflected on stable storage.

Good point, Dave.  The text below if what I suggest we add
to cover this point.

--
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.

---

From: Mike Eisler <[email-masked]>
Date: Fri, 4 Feb 2000 11:53:47 -0800 (PST)

> 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?

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 04 Feb 2000 14:04:12 -0600

> hasn't sent back to the client?

So if we leave this statement but make it purely about the ordering
of what is stored/reflected in stable storage (regardless of if
a response was returned), it would be more appropriate and useful?
It would then match or compliment the execution ordering of compound
operations.

Better approach?

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Fri, 4 Feb 2000 12:33:31 -0800 (PST)

> It would then match or compliment the execution ordering of compound

I didn't understand what your rationale was until Dave explained it. Given
that, proposed text implies that the server would know when it hadn't send
results, i.e. the server would know when it was about to crash, and so would
reactively synchronize the operations it had executed. This is a variant of
the Halting Problem, and barring breakthroughs in time travel, known to be
unsolvable. 

So any statement on this issue needs to avoid discussing what the server might
*choose* to do when it sends no results. There is no choice.

	-mre

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 04 Feb 2000 14:43:09 -0600

> *choose* to do when it sends no results. There is no choice.

Here is my proposed revision then:
--

13.3.  Synchronous Modifying Operations

   NFS version 4 operations that modify the file system are synchronous.
   When an operation is successfully completed at the server, the client
   can depend that any data associated with the request is now on stable
   storage.  This implies that any previous operations within the same
   compound request are also reflected in stable storage.  This behavior
   enables the client's ability to recover from a partially executed
   compound request which may resulted from the failure of the server.
   For example, if a compound request contains operations A and B and
   the server is unable to send a response to the client, depending on
   the progress the server made in servicing the request 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.