Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-pnfs-obj-07.txt

From: [email-masked]
Date: Tue, 1 Apr 2008 12:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title           : Object-based pNFS Operations
	Author(s)       : B. Halevy, et al.
	Filename        : draft-ietf-nfsv4-pnfs-obj-07.txt
	Pages           : 35
	Date            : 2008-04-01

This Internet-Draft provides a description of the object-based pNFS
extension for NFSv4.  This is a companion to the main pnfs
specification in the NFSv4 Minor Version 1 Internet Draft, which is
currently draft-ietf-nfsv4-minorversion1-21.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-pnfs-obj-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Benny Halevy <[email-masked]>
Date: Wed, 02 Apr 2008 08:48:18 +0300

draft -07 contains the following changes:

* XDR definitions reorganized.
  - Text clarified, reference to NFSV4.1 XDR types added.
  - Second copy of each definition was removed.
  - Embedded definitions prefixed with "///" for scripted extraction.
  - Definitions were reordered so that types are always defined before
    they are uses.
  - Nested union type definitions taken out of struct pnfs_osd_deviceaddr4.
  - All member names were prefixed with an abbreviation of the type name.
  - References to such members scrubbed.

* pnfs_osd_object_cred4:
  Included reference to GETDEVICEINFO with regards to capability privacy consideration
  as the cred can be passed as part of the device info (for the root object)

* pnfs_osd_layoutupdate4:
  Added following descriptive paragraph:
	Object-Based pNFS clients are not allowed to modify the layout.
	Therefore, the information passed in pnfs_osd_layoutupdate4
	is used only to update the file's attributes.
	In addition to the generic information the client can pass to the metadata
	server in LAYOUTCOMMIT such as the highest offset the client wrote to and
	the last time it modified the file, the client MAY use pnfs_osd_layoutupdate4
	to convey the capacity consumed (or released) by writes using the layout,
	and to indicate that I/O errors were encountered by such writes.

* pnfs_osd_deltaspaceused4
  Since the current-command capacity utilization attribute is still
  T.B.D. in the OSDv2 standard, the following comment was added to allow
  a mechanism that would still provide for interoperability using a well-defined,
  vendor specific attribute:
	(*) Note: At the time this document is written,
	a per-command used capacity attribute is not yet standardized
	by <xref target="OSD2">OSD2 draft</xref>.
	The client MAY use vendor-specific attributes to calculate space utilization,
	provided that the vendor defines and publishes a suitable vendor-specific
	attributes page for current-command attributes as defined by
	<xref target="OSD2">OSD2 draft</xref>, Section 7.1.2.2.

* pnfs_osd_layoutreturn4:
  Added clarification text for the no-errors case 
	When OSD I/O operations failed, "olr_ioerr_report<>" is used to
	report these errors to the metadata server as an array of elements of
	type pnfs_osd_ioerr4.  Each element in the array represents an error
	that occured on the object specified by oer_component.  If no errors
	are to be reported, the size of the olr_ioerr_report<> array is set
	to zero.

* Added reference to NFSv4.1 XDR I-D (Informative for now, will be moved
  to Normative when it becomes an RFC)

* Other, minor word smithing:

 The server should make an attempt to honor the hints 
 but it can ignore any or all of them at its own discretion and
-without failing the respective create operation.
+without failing the respective CREATE operation.
 
 There is no requirement in the protocol for any relationship between
 byte ranges used in LAYOUTGET to acquire layouts and byte ranges used
 in CB_LAYOUTRECALL, LAYOUTCOMMIT, or LAYOUTRETURN.
-However, using OSD capabilities poses limitations on these operations
+However, using OSD byte-range capabilities poses limitations on these operations
 since the capabilities associated with layout segments cannot be merged
 or split.

 This section describes the different data mapping schemes
 in detail.
 The object layout always uses a "dense"
-layout as described in the pNFS document.
+layout as described in
+<xref target="NFSv4.1">NFSv4.1 draft</xref>.

-If group_width is also non-zero, then the size MUST be a
-multiple of group_width * (mirror_cnt+1).
+If odm_group_width is also non-zero, then the size of the olo_components array MUST be a
+multiple of odm_group_width * (odm_mirror_cnt+1).

-or the last in each group if group_width is > zero,
+or the last in each group (if odm_group_width is greater than zero),

 PNFS_OSD_RAID_5 means that the position of the parity data
-is rotated on each stripe.  In the first stripe, the last
+is rotated on each stripe or each group (if odm_group_width is greater than zero).
+In the first stripe, the last

Benny

On Apr. 01, 2008, 22:00 +0300, [email-masked] wrote:
> ------------------------------------------------------------------------
>