Subject: [nfsv4] plane trips, the draft spec and me.

From: Robert Gordon <[email-masked]>
Date: Thu, 08 May 2008 01:09:26 -0700

I started to re-read the draft spec from chapter 12, and have
some minor nitty suggestions, and one error (use of client
in place of server) in the block "@@ -212,7 +211,7 @@"

--
Robert.

--- nfsv41_middle_pnfs-org.xml	2008-05-07 12:52:28.000000000 -0700
+++ nfsv41_middle_pnfs.xml	2008-05-07 15:44:27.000000000 -0700
@@ -44,13 +44,13 @@
  </t>
  <t>
    pNFS takes the form of OPTIONAL operations that manage protocol
-  objects called 'layouts' which contain data location information.
-  The layout is managed in a similar fashion as NFSv4.1 data
-  delegations are managed.  For example, the layout is leased,
-  recallable and revocable.  However, layouts are distinct
-  abstractions and are manipulated with new operations.  When a client
-  holds a layout, it is granted the ability to access the data location
-  directly using the location information specified in the layout.
+  objects called 'layouts' which contain a byte-range and storage
+  location information.  The layout is managed in a similar fashion
+  as NFSv4.1 data delegations.  For example, the layout is leased,
+  recallable and revocable.  However, layouts are distinct abstractions
+  and are manipulated with new operations.  When a client holds a
+  layout, it is granted the ability to directly access the byte-range
+  at the storage location specified in the layout.
  </t>
  <t>
    There are interactions between layouts and other NFSv4.1
@@ -103,13 +103,13 @@
  <section title="pNFS Definitions">
  <t>
    NFSv4.1's pNFS feature partitions the file system protocol into two
-  parts: metadata and data.  Where data is the contents of a file and
-  metadata is "everything else".  The metadata functionality is
-  implemented by a metadata server that supports pNFS and the
-  operations described in (<xref target="nfsv41operations" />).  The
-  data functionality is implemented by a storage device that supports
-  the storage protocol.  A subset (defined in <xref target="ds_ops"
-  />) of NFSv4.1 itself is one such storage protocol.  New terms are
+  parts: metadata and data.  Where data being the contents of a file  
and
+  the metadata is "everything else".  The metadata functionality is
+  implemented by a NFSv4.1 server that supports pNFS and the
+  operations described in (<xref target="nfsv41operations" />) (a  
metadata server).
+  The data functionality is implemented by a storage device that  
supports
+  a storage protocol.  A subset (defined in <xref target="ds_ops"
+  />) of NFSv4.1 is one such storage protocol.  New terms are
    introduced to the NFSv4.1 nomenclature and existing terms are
    clarified to allow for the description of the pNFS feature.
  </t>
@@ -125,11 +125,11 @@

  <section title="Metadata Server">
  <t>
    architectural choices exists for the metadata server and its use of
-  what file system information is held at the server.  Some servers may
-  contain metadata only for the file objects that reside at the
-  metadata server while file data resides on the associated storage
+  file system information held at the server.  Some servers may
+  contain metadata only for file objects residing at the
+  metadata server while the file data resides on associated storage
    devices.  Other metadata servers may hold both metadata and a
    varying degree of file data.
  </t>
@@ -137,9 +137,8 @@

  <section title="pNFS Client">
  <t>
-  An NFSv4.1 client that supports pNFS operations and supports at
-  least one storage protocol or layout type for performing I/O
-  to storage devices.
+  A NFSv4.1 client that supports pNFS operations and supports at
+  least one storage protocol for performing I/O to storage devices.
  </t>
  </section>

@@ -193,9 +192,9 @@
    experimentation.
  </t>
  <t>
-  As an example,  layout of the
-  file layout type could be an array of tuples (e.g.,
-  deviceID, file_handle), along with a definition of how the data is
+  As an example,  the organization of the file layout type could be
+  an array of tuples (e.g., deviceID, file_handle), along with a
+  definition of how the data is
    stored across the devices (e.g., striping). A block/volume layout
    might be an array of tuples that store &lt;deviceID, block_number,
    block count&gt; along with information about block size and the
@@ -212,7 +211,7 @@
    The response for these operations will include structures such
    a device_addr4 or a layout4, each of which includes a layout type  
within
    it.  The layout type sent by the server MUST always be the same
-  one requested by the client.  When a client sends a response that
+  one requested by the client.  When a server sends a response that
    includes a different layout type, the client SHOULD ignore the
    response and behave as if the server had returned an error response.
  </t>
@@ -249,9 +248,9 @@
    target="layoutiomode4" />) indicates to the metadata server the
    client's intent to perform either just read operations
    or a mixture of I/O possibly containing read
-  and write operations. For certain layout
-  types, it is useful for a client to specify this intent at LAYOUTGET
-  (<xref target="OP_LAYOUTGET" />) time.  For example, block/volume
+  and write operations. For certain layout types, it is useful for a
+  client to specify this intent at the time
+  it issues a LAYOUTGET (<xref target="OP_LAYOUTGET" />).  For  
example, block/volume
    based protocols, block allocation could occur when a READ/WRITE
    iomode is specified.  A special LAYOUTIOMODE4_ANY iomode is defined
    and can only be used for LAYOUTRETURN and CB_LAYOUTRECALL, not for
@@ -259,20 +258,20 @@
    READ/WRITE iomodes are being returned or recalled, respectively.
  </t>
  <t>
-  A storage device may validate I/O with regards to the iomode; this
+  A storage device may validate I/O with regard to the iomode; this
    is dependent upon storage device implementation and layout type.
    Thus, if the client's layout iomode is inconsistent with the I/O
    being performed, the storage device may reject the client's I/O with
-  an error indicating a new layout with the correct I/O mode should be
-  fetched.  For example, if a client gets a layout with a READ iomode  
and
-  performs a WRITE to a storage device, the storage device is allowed
-  to reject that WRITE.
+  an error indicating a new layout with the correct iomode should be
+  obtained via LAYOUTGET. For example, if a client gets a layout with
+  a READ iomode and performs a WRITE to a storage device, the storage
+  device is allowed to reject that WRITE.
  </t>
  <t>
-  The iomode does not conflict with OPEN share modes or lock requests;
-  open mode and lock conflicts are enforced as they are without the
-  use of pNFS, and are logically separate from the pNFS layout level.
-  As well, open modes and locks are the preferred method for
+  The use of the layout iomode does not conflict with OPEN share modes
+  or lock requests; open mode and lock conflicts are enforced as they
+  are without the use of pNFS, and are logically separate from the pNFS
+  layout level. Open modes and locks are the preferred method for
    restricting user access to data files.  For example, an OPEN of  
read,
    deny-write does not conflict with a LAYOUTGET containing an iomode
    of READ/WRITE performed by another client.  Applications that depend
@@ -283,10 +282,10 @@

  <section title="Device IDs" anchor="device_ids">
    <t>
-    The device ID (data type deviceid4, see
-    <xref target="deviceid4"/>) names a group of storage devices. The  
scope
-    of a device ID is per pair of client ID and layout type. In  
practice, a
-    significant amount of information may be required to fully address
+    The device ID (data type deviceid4, see <xref target="deviceid4"/ 
 >) names
+    a group of storage devices. The scope of a device ID is the tuple
+    &lt;client ID, layout type&gt;. In practice, a significant amount  
of information may
+    be required to fully address
      a storage device.  Rather than embedding all such information in a
      layout, layouts embed device IDs.  The NFSv4.1 operation
      GETDEVICEINFO (<xref target="OP_GETDEVICEINFO" />) is used to

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