All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 10/11] NFSv4.1: Enable open-by-filehandle
Date: Tue, 19 Mar 2013 14:16:15 +0000	[thread overview]
Message-ID: <1363702570.7515.6.camel@leira.trondhjem.org> (raw)
In-Reply-To: <20130319140901.GB7912@fieldses.org>

On Tue, 2013-03-19 at 10:09 -0400, J. Bruce Fields wrote:
> On Tue, Mar 19, 2013 at 09:07:42AM -0400, Trond Myklebust wrote:
> > Sometimes, we actually _want_ to do open-by-filehandle, for instance
> > when recovering opens after a network partition, or when called
> > from nfs4_file_open.
> > Enable that functionality using a new capability NFS_CAP_ATOMIC_OPEN_V1,
> > and which is only enabled for NFSv4.1 servers that support it.
> 
> So you're assuming NFS4ERR_INVAL is how the server indicates lack of
> support?

Looking at the list of valid errors for OPEN in section 15.2 of RFC5661,
I don't see what else fits the bill.

> Looking back at NFS server history.... I think that's what it did before
> supporting these types, but I wonder if that was really right.  Possibly
> it's just a bug not to support the new claim types in a 4.1 server.

I've assumed that it isn't. NFSv4.1 is the very first minor version, so
it's not supposed to contain any mandatory new features. Yes, I know we
broke the rules on that one in spectacular fashion with sessions, but
I'm assuming that is the only exception...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

  reply	other threads:[~2013-03-19 14:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19 13:07 [PATCH 01/11] NFSv4: Fail I/O if the state recovery fails irrevocably Trond Myklebust
2013-03-19 13:07 ` [PATCH 02/11] NFS: Don't accept more reads/writes if the open context recovery failed Trond Myklebust
2013-03-19 13:07   ` [PATCH 03/11] NFS: __nfs_find_lock_context needs to check ctx->lock_context for a match too Trond Myklebust
2013-03-19 13:07     ` [PATCH 04/11] NFSv4: The stateid must remain the same for replayed RPC calls Trond Myklebust
2013-03-19 13:07       ` [PATCH 05/11] NFSv4: Resend the READ/WRITE RPC call if a stateid change causes an error Trond Myklebust
2013-03-19 13:07         ` [PATCH 06/11] NFSv4: Prepare for minorversion-specific nfs_server capabilities Trond Myklebust
2013-03-19 13:07           ` [PATCH 07/11] NFSv4.1: Select the "most recent locking state" for read/write/setattr stateids Trond Myklebust
2013-03-19 13:07             ` [PATCH 08/11] NFSv4: Clean up nfs4_opendata_alloc in preparation for NFSv4.1 open modes Trond Myklebust
2013-03-19 13:07               ` [PATCH 09/11] NFSv4.1: Add xdr support for CLAIM_FH and CLAIM_DELEG_CUR_FH opens Trond Myklebust
2013-03-19 13:07                 ` [PATCH 10/11] NFSv4.1: Enable open-by-filehandle Trond Myklebust
2013-03-19 13:07                   ` [PATCH 11/11] NFSv4.1: Use CLAIM_DELEG_CUR_FH opens when available Trond Myklebust
2013-03-19 14:09                   ` [PATCH 10/11] NFSv4.1: Enable open-by-filehandle J. Bruce Fields
2013-03-19 14:16                     ` Myklebust, Trond [this message]
2013-03-19 14:32                       ` J. Bruce Fields
2013-03-19 14:41                         ` Myklebust, Trond
2013-03-19 14:45                           ` Myklebust, Trond
2013-03-19 15:16                             ` J. Bruce Fields
2013-03-19 14:50                           ` J. Bruce Fields
2013-03-19 15:16                             ` Myklebust, Trond
2013-03-19 15:23                               ` J. Bruce Fields
2013-03-19 16:37                                 ` Myklebust, Trond
2013-03-21 15:25                                   ` J. Bruce Fields
2013-03-25 20:12                                     ` Steve Dickson
2013-03-19 17:29                   ` Adamson, Andy
2013-03-19 17:42                     ` Myklebust, Trond

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1363702570.7515.6.camel@leira.trondhjem.org \
    --to=trond.myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.