Re: [nfsv4] [PATCH 1/1] pnfsd: DLM file layout only support read iomode layouts

"J. Bruce Fields" <bfields@fieldses.org> Wed, 16 December 2009 16:30 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E923A69F8 for <nfsv4@core3.amsl.com>; Wed, 16 Dec 2009 08:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh9TwXhWUn5m for <nfsv4@core3.amsl.com>; Wed, 16 Dec 2009 08:30:25 -0800 (PST)
Received: from fieldses.org (fieldses.org [174.143.236.118]) by core3.amsl.com (Postfix) with ESMTP id 06D503A6A2E for <nfsv4@ietf.org>; Wed, 16 Dec 2009 08:30:25 -0800 (PST)
Received: from bfields by fieldses.org with local (Exim 4.69) (envelope-from <bfields@fieldses.org>) id 1NKwlU-0006P7-2u; Wed, 16 Dec 2009 11:30:16 -0500
Date: Wed, 16 Dec 2009 11:30:16 -0500
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Benny Halevy <bhalevy@panasas.com>
Message-ID: <20091216163016.GB24044@fieldses.org>
References: <1260907434-7484-1-git-send-email-andros@netapp.com> <1260907434-7484-2-git-send-email-andros@netapp.com> <20091215224155.GF8686@fieldses.org> <4B28D006.4000409@panasas.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4B28D006.4000409@panasas.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: andros@netapp.com, pnfs@linux-nfs.org, NFSv4 <nfsv4@ietf.org>
Subject: Re: [nfsv4] [PATCH 1/1] pnfsd: DLM file layout only support read iomode layouts
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 16 Dec 2009 16:30:26 -0000

On Wed, Dec 16, 2009 at 02:18:14PM +0200, Benny Halevy wrote:
> Bruce, I agree that the spec isn't clear about what to return
> so I'm adding the ietf list to this thread.
> 
> In summary, we have a server that supports read-only layouts but
> not read-write.  What should it return to a LAYOUTGET with LAYOUTIOMODE4_RW?
> 
> We see two possibilities that make sense: NFS4ERR_BADIOMODE and
> NFS4ERR_LAYOUTUNAVAILABLE.
> 
> 15.1.10.1.  NFS4ERR_BADIOMODE (Error Code 10049)
> 
>    An invalid or inappropriate layout iomode was specified.
> 
> 15.1.10.4.  NFS4ERR_LAYOUTUNAVAILABLE (Error Code 10059)
> 
>    Returned when layouts are not available for the current file system
>    or the particular specified file.
> 
> NFS4ERR_BADIOMODE seems to make more sense since layouts are available,
> just not for the requested iomode. However its definition indicates that
> the iomode in the client request is "invalid or inappropriate".
> It is not clear what "inappropriate" means in this context.
> I guess that the original intent was for clients who e.g. send a LAYOUTGET
> with LAYOUTIOMODE4_ANY which is a valid iomode but inappropriate for LAYOUTGET.
> 
> To make the spec clearer we could say:
> 
> 15.1.10.1.  NFS4ERR_BADIOMODE (Error Code 10049)
> 
>    An invalid, inappropriate, or unsupported layout iomode was specified.

Sounds OK to me.

A mention of BADIOMODE in 13.8 might help too:

	For example, if the server implementation supports reading from
	read-only replicas or mirrors, it would be useful for the server
	to return a layout enabling the client to do so.  As such, the
	client SHOULD set the iomode based on its intent to read or
	write the data.  In such a case, the server will respond
	NFS4ERR_BADIOMODE to a client that requests an iomode which it
	does not support for the given file.

But I don't know if it's too late for that kind of change.

Probably "invalid" was actually meant for iomode's other than those
defined by the spec, the word "inappropriate" was added to cover the
layoutget IOMODE4_ANY case, and the read-only data server case wasn't
considered.  I dunno.

--b.