Subject: RE: [nfsv4] pNFS - file commit

From: "Halevy, Benny" <[email-masked]>
Date: Mon, 3 Oct 2005 19:23:02 -0400

Garth Goodson wrote:
> Halevy, Benny wrote:
> > Dave, I think we're mixing two distinct cases, both
> > involve a COMMIT sent to the MDS.
> > 
> > Case 1 is where the MDS itself accepted asynchronous writes
> > from either pnfs or nfsv4 clients.  In this case the MDS
> > MUST flush the dirty data to stable storage, i.e. it should
> > either write the data to the DSs synchronously or write
> > asynchronously and follow with a COMMIT to the DSs to
> > ensure the written data reached stable storage.
> > 
> Case 1 is covered in the text.  COMMITs to the metadata 
> server are for 
> writes that went to the metadata server.
> 

Not exactly.  The current text does not require the MDS
to ensure data reached stable storage on the DSs which
I think we both agree it should.  It only requires it
to write the data to the DSs so it would be visible
there which is not quite the same thing. Quoting
from draft-welch-pnfs-ops-04.txt:

3.6  Asynchronous write propagation

   Asynchronous writes written through the metadata server may be
   propagated lazily to the data servers.  For asynchronously written
   data, a client performing a READ at the appropriate data server is
   not guaranteed to see the newly written data until a COMMIT occurs at
   the metadata server.  While the WRITE is pending reads to the data
   server can give out the old data, the new data, or a mixture thereof.
   After the WRITE completes (is committed for asynchronous writes), the
   data servers must give out the new data.

I'd add something like the following text here: "In response to a COMMIT
operation, the metadata server MUST ensure that all data written
asynchronously through it will be written to the appropriate data
servers either synchronously or asynchronously and successfully committed
to stable storage using a NFS COMMIT operation for NFSv4 data servers or
an equivalent operation to other storage types, e.g. the OSD FLUSH operation
for Object-based Storage Devices."

   If the server implements
   its storage in any way such that it cannot obey these constraints,
   then it must recall the layouts to prevent reads being done that
   cannot be handled correctly.

[snip]

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Garth Goodson <[email-masked]>
Date: Mon, 03 Oct 2005 17:02:56 -0700

> for Object-based Storage Devices."
Ok.  But I believe that was the intent. I'll add something to clarify.

-Garth

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 04 Oct 2005 09:07:42 -0400

> from draft-welch-pnfs-ops-04.txt:

If the client is writing to the metadata server, then it is using
standard NFSv4, not the pNFS extensions. The behaviour of COMMIT in this
situation is therefore already covered by RFC3530.

Cheers,
  Trond

---

From: Dean Hildebrand <[email-masked]>
Date: Tue, 4 Oct 2005 10:58:40 -0400 (EDT)

Garth, can you post draft-welch-pnfs-ops-04.txt somewhere?  I don't seem
to have it and a google search only locates -03.

Dean