draft-ietf-nfsv4-scsi-layout-07.txt   draft-ietf-nfsv4-scsi-layout-08.txt 
NFSv4 C. Hellwig NFSv4 C. Hellwig
Internet-Draft Internet-Draft
Intended status: Standards Track August 16, 2016 Intended status: Standards Track August 26, 2016
Expires: February 17, 2017 Expires: February 27, 2017
Parallel NFS (pNFS) SCSI Layout Parallel NFS (pNFS) SCSI Layout
draft-ietf-nfsv4-scsi-layout-07.txt draft-ietf-nfsv4-scsi-layout-08.txt
Abstract Abstract
The Parallel Network File System (pNFS) allows a separation between The Parallel Network File System (pNFS) allows a separation between
the metadata (onto a metadata server) and data (onto a storage the metadata (onto a metadata server) and data (onto a storage
device) for a file. The SCSI Layout Type is defined in this document device) for a file. The SCSI Layout Type is defined in this document
as an extension to pNFS to allow the use SCSI based block storage as an extension to pNFS to allow the use SCSI based block storage
devices. devices.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 17, 2017. This Internet-Draft will expire on February 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 6 skipping to change at page 4, line 6
defining document for the existing block layout type. [RFC6688] is defining document for the existing block layout type. [RFC6688] is
unnecessary in the context of the SCSI layout type because the new unnecessary in the context of the SCSI layout type because the new
layout type provides mandatory disk access protection as part of the layout type provides mandatory disk access protection as part of the
layout type definition. In contrast to [RFC5663], this document uses layout type definition. In contrast to [RFC5663], this document uses
SCSI protocol features to provide reliable fencing by using SCSI SCSI protocol features to provide reliable fencing by using SCSI
Persistent Reservations, and it can provide reliable and efficient Persistent Reservations, and it can provide reliable and efficient
device discovery by using SCSI device identifiers instead of having device discovery by using SCSI device identifiers instead of having
to rely on probing all devices potentially attached to a client. to rely on probing all devices potentially attached to a client.
This new layout type also optimizes the I/O path by reducing the size This new layout type also optimizes the I/O path by reducing the size
of the LAYOUTCOMMIT payload. Except for these changes the protocol of the LAYOUTCOMMIT payload.
is identical to [RFC5663], most importantly there are no changes to
way the volume topology is built Section 2.3.2, and the data The above two paragraphs summarize the major functional differences
structures that describe extents Section 2.4 are unchanged compared from [RFC5663]. There are other minor differences, e.g., the "base"
to [RFC5663] as well. volume type in this specification is used instead of the "simple"
volume type in [RFC5663], but there are no significant differences in
the data structures that describe the volume topology above this
level Section 2.3.2 or in the data structures that describe extents
Section 2.4.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. General Definitions 1.2. General Definitions
The following definitions are provided for the purpose of providing The following definitions are provided for the purpose of providing
skipping to change at page 25, line 42 skipping to change at page 25, line 42
thereby enforced. thereby enforced.
If I/O is done by a principal different from the one that opened the If I/O is done by a principal different from the one that opened the
file, the client SHOULD send the I/O to be performed by the metadata file, the client SHOULD send the I/O to be performed by the metadata
server rather than doing it directly to the storage device. server rather than doing it directly to the storage device.
3.3. Enforcing Locking Restrictions 3.3. Enforcing Locking Restrictions
Mandatory enforcement of whole-file locking by means of share Mandatory enforcement of whole-file locking by means of share
reservations is provided when the pNFS client obeys the requirement reservations is provided when the pNFS client obeys the requirement
set forth in Section 2.1 above. Since performing I/O requires a set forth in Section 3.1 above. Since performing I/O requires a
valid open stateid an I/O that violates an existing share reservation valid open stateid an I/O that violates an existing share reservation
would only be possible when the server allows conflicting open would only be possible when the server allows conflicting open
stateids to exist. stateids to exist.
The nature of the SCSI layout type is such implementation/enforcement The nature of the SCSI layout type is such implementation/enforcement
of mandatory byte-range locks is very difficult. Given that layouts of mandatory byte-range locks is very difficult. Given that layouts
are granted to clients rather than owners, the pNFS client is in no are granted to clients rather than owners, the pNFS client is in no
position to successfully arbitrate among multiple lockowners on the position to successfully arbitrate among multiple lockowners on the
same client. Suppose lockowner A is doing a write and, while the I/O same client. Suppose lockowner A is doing a write and, while the I/O
is pending, lockowner B requests a mandatory byte-range for a byte is pending, lockowner B requests a mandatory byte-range for a byte
 End of changes. 5 change blocks. 
10 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/