From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Benny Halevy <bhalevy@panasas.com>
Cc: linux-nfs@vger.kernel.org, nfsv4@linux-nfs.org
Subject: Re: [PATCH 0/2 v4] nfs: return nfs4 compound header status on op header decoding error
Date: Thu, 17 Jul 2008 08:09:02 -0400 [thread overview]
Message-ID: <1216296542.7453.19.camel@localhost> (raw)
In-Reply-To: <487DF62C.80501@panasas.com>
On Wed, 2008-07-16 at 16:22 +0300, Benny Halevy wrote:
> On Jul. 16, 2008, 15:57 +0300, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > Why do we need to handle OP_ILLEGAL in the first place? This is the
> > client; it isn't supposed to send illegal operations...
>
> Right, but it helps in the development process when dealing with
> a broken version of the server or the client to pass a less
> generic error (-EOPNOTSUPP) up the stack rather than -EIO.
NFS4ERR_OP_ILLEGAL literally means "this operation isn't even listed in
the 4.0/4.1 RFC". That's out in EYOUUTTERLYINSANECLIENT territory, and
so the current mapping to EOPNOTSUPP is just wrong.
NFS4ERR_NOTSUPP is the correct return value if a server doesn't (yet)
support an operation.
next prev parent reply other threads:[~2008-07-17 12:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-31 14:35 [PATCH 0/2] nfsv4 compound status Benny Halevy
2008-03-31 14:39 ` [PATCH 1/2] nfs: return negative error value from nfs{,4}_stat_to_errno Benny Halevy
2008-03-31 14:48 ` [PATCH 2/2] nfs: use compound hdr.status to override op status Benny Halevy
2008-03-31 22:25 ` Trond Myklebust
[not found] ` <1207002349.15341.15.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-04-01 9:37 ` Benny Halevy
2008-04-01 9:41 ` [PATCH 2/2 v1] " Benny Halevy
2008-05-09 22:21 ` [PATCH 1/1 v2] " Benny Halevy
2008-05-09 23:32 ` Benny Halevy
2008-05-10 6:11 ` Benny Halevy
2008-05-09 23:38 ` [PATCH " Benny Halevy
2008-05-10 17:24 ` Trond Myklebust
2008-05-11 23:21 ` [PATCH v3] " Benny Halevy
2008-05-11 23:26 ` Trond Myklebust
2008-05-12 1:54 ` Benny Halevy
2008-07-03 17:49 ` [PATCH 0/2 v4] nfs: return nfs4 compound header status on op header decoding error Benny Halevy
2008-07-03 17:52 ` [PATCH 1/2] " Benny Halevy
2008-07-03 18:42 ` [PATCH 2/2] nfs: remove incorrect usage of nfs4 compound response hdr.status Benny Halevy
2008-07-15 21:57 ` [PATCH 0/2 v4] nfs: return nfs4 compound header status on op header decoding error Trond Myklebust
2008-07-16 8:21 ` Benny Halevy
2008-07-16 12:57 ` Trond Myklebust
2008-07-16 13:22 ` Benny Halevy
2008-07-17 12:09 ` Trond Myklebust [this message]
2008-07-17 13:20 ` Benny Halevy
2008-07-21 16:59 ` [PATCH] nfs: return compound hdr.status when there are no op replies Benny Halevy
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=1216296542.7453.19.camel@localhost \
--to=trond.myklebust@fys.uio.no \
--cc=bhalevy@panasas.com \
--cc=linux-nfs@vger.kernel.org \
--cc=nfsv4@linux-nfs.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.