Re: [nfsv4] Review comments for WGLC of draft-ietf-nfsv4-layout-types

hch <hch@lst.de> Thu, 17 August 2017 07:32 UTC

Return-Path: <hch@lst.de>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9041327FE for <nfsv4@ietfa.amsl.com>; Thu, 17 Aug 2017 00:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp2FUQQpbXl9 for <nfsv4@ietfa.amsl.com>; Thu, 17 Aug 2017 00:32:24 -0700 (PDT)
Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42421327EC for <nfsv4@ietf.org>; Thu, 17 Aug 2017 00:32:23 -0700 (PDT)
Received: by newverein.lst.de (Postfix, from userid 2407) id 6AC5B68C38; Thu, 17 Aug 2017 09:32:21 +0200 (CEST)
Date: Thu, 17 Aug 2017 09:32:21 +0200
From: hch <hch@lst.de>
To: Thomas Haynes <loghyr@primarydata.com>
Cc: hch <hch@lst.de>, Chuck Lever <chuck.lever@oracle.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Message-ID: <20170817073221.GB24203@lst.de>
References: <418E308E-5057-499A-B403-38486BDEF772@oracle.com> <20170816090444.GA21357@lst.de> <88A11EE3-3866-4F9D-8FA5-9C5A95887203@primarydata.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <88A11EE3-3866-4F9D-8FA5-9C5A95887203@primarydata.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/HZr24wIjog6QVpQuiPNbWep2SP8>
Subject: Re: [nfsv4] Review comments for WGLC of draft-ietf-nfsv4-layout-types
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Aug 2017 07:32:27 -0000

On Wed, Aug 16, 2017 at 05:56:48PM +0000, Thomas Haynes wrote:
> RFC8154 doesn’t quite say that:
> 
>    The Server to Storage System protocol, called the "Control Protocol",
>    is not of concern for interoperability, although it will typically be
>    the same SCSI-based storage protocol.
> 
> I read that to say that it is possible for someone to implement the SCSI
> layout without using the SCSI-based storage protocol. 

Looks like that was a bad copy and paste job from the block layout.
I need to have a word with the lead author ;-)

> But based on the sentence above, I see a SHOULD on the use of the
> SCSI-based storage protocol as a control protocol and not a MUST.

In terms of interop it's indeed not a MUST - just the observable
behavior MUST be as if it was used, which is very close to the same.

> And given that RFC5663 also states:
> 
>    While the Server to
>    Storage System protocol, called the "Control Protocol", is not of
>    concern for interoperability here, it will typically also be a
>    block/volume protocol when clients use block/ volume protocols.
> 
> and we don’t consider that layout type to have a control protocol.

The big difference between the block and the scsi layout is that
the former does not specify a fencing protocol - and it turns out
implementing one is basically impossible except for a corner case.

> I think you are arguing that since RFC5663 did not address directly
> how the mds would fence the client and RFC8154 does, that
> a full control protocol does exist in RFC8154.  And that the
> sentence in question should read:
> 
> 
>    The Server to Storage System protocol, called the "Control Protocol",
>    is the same SCSI-based storage protocol.

Yes.

> I thought this covered that?
> 
>    In the context of fencing off of the client upon revocation of a
>    layout, these limitations come into play again, i.e., the granularity
>    of the fencing can only be at the host/logical-unit level.  Thus, if
>    one of a client's layouts is revoked by the server, it will
>    effectively revoke all of the client's layouts for files located on
>    the storage units comprising the logical volume.  This may extend to
>    the client's layouts for files in other file systems.  Clients need
>    to be prepared for such revocations and reacquire layouts as needed.

Ok.