From: "J. Bruce Fields" <[email protected]>
The code seems to work. The protocol looks stable. The kernel's
version defaults can be overridden by rpc.nfsd arguments.
Signed-off-by: J. Bruce Fields <[email protected]>
---
fs/nfsd/nfssvc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
index 314f5c8f8f1a..9277cc91c21b 100644
--- a/fs/nfsd/nfssvc.c
+++ b/fs/nfsd/nfssvc.c
@@ -119,6 +119,7 @@ struct svc_program nfsd_program = {
static bool nfsd_supported_minorversions[NFSD_SUPPORTED_MINOR_VERSION + 1] = {
[0] = 1,
[1] = 1,
+ [2] = 1,
};
int nfsd_vers(int vers, enum vers_op change)
--
1.9.3
On Mon, Feb 02, 2015 at 11:15:57AM -0500, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <[email protected]>
>
> The code seems to work. The protocol looks stable. The kernel's
> version defaults can be overridden by rpc.nfsd arguments.
Does it really make sense to enabled this without READ_PLUS support
or implementing the various new attributes?
Also should we add a wiki page with the 4.2 status?
On Wed, Feb 11, 2015 at 04:37:57AM -0800, Christoph Hellwig wrote:
> On Mon, Feb 02, 2015 at 11:15:57AM -0500, J. Bruce Fields wrote:
> > From: "J. Bruce Fields" <[email protected]>
> >
> > The code seems to work. The protocol looks stable. The kernel's
> > version defaults can be overridden by rpc.nfsd arguments.
>
> Does it really make sense to enabled this without READ_PLUS support
> or implementing the various new attributes?
I think so. That's all optional--e.g. for READ_PLUS clients can
determine server support using ERR_OP_NOTSUPP (or whatever it's called),
and for attributes they can query the supported_attributes attribute.
It's possible we'll never support everything in 4.2.
> Also should we add a wiki page with the 4.2 status?
Sounds like a good idea.
--b.
On Wed, Feb 11, 2015 at 09:12:57AM -0500, J. Bruce Fields wrote:
> I think so. That's all optional--e.g. for READ_PLUS clients can
> determine server support using ERR_OP_NOTSUPP (or whatever it's called),
> and for attributes they can query the supported_attributes attribute.
> It's possible we'll never support everything in 4.2.
The questions is if we need a useful subset of 4.2 to bother. I doubt
we'll ever bother with ADBs for example, and the copy offload might
take a while to get everyting sorted. But exposting most attributes
and supporting READ_PLUS sounds like important enought to implement
before considering 4.2 ready.
On Wed, Feb 11, 2015 at 06:16:19AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 11, 2015 at 09:12:57AM -0500, J. Bruce Fields wrote:
> > I think so. That's all optional--e.g. for READ_PLUS clients can
> > determine server support using ERR_OP_NOTSUPP (or whatever it's called),
> > and for attributes they can query the supported_attributes attribute.
> > It's possible we'll never support everything in 4.2.
>
> The questions is if we need a useful subset of 4.2 to bother.
Internally the virtualization people have been interested in ALLOCATE,
SEEK, and security labels, so I'm assuming we've passed that sort of
minimum "is there any benefit at all to turning this on" threshhold.
> I doubt we'll ever bother with ADBs for example, and the copy offload
> might take a while to get everyting sorted. But exposting most
> attributes and supporting READ_PLUS sounds like important enought to
> implement before considering 4.2 ready.
I agree there's a documentation and marketing problem: it would simplify
communication with users if "this server supports 4.2" reliably meant
support for some minimum list of features. Is that what you're thinking
about?
Individual distros and other server vendors may make their own decisions
here, so I don't know if we do much about that on our own.
We could also add a little more data e.g. to /proc/self/mountstats to
help figure out stuff like "why does copying a big file go so much
faster on server X than server Y?".
--b.
On Wed, Feb 11, 2015 at 9:54 AM, J. Bruce Fields <[email protected]> wrote:
> On Wed, Feb 11, 2015 at 06:16:19AM -0800, Christoph Hellwig wrote:
>> On Wed, Feb 11, 2015 at 09:12:57AM -0500, J. Bruce Fields wrote:
>> > I think so. That's all optional--e.g. for READ_PLUS clients can
>> > determine server support using ERR_OP_NOTSUPP (or whatever it's called),
>> > and for attributes they can query the supported_attributes attribute.
>> > It's possible we'll never support everything in 4.2.
>>
>> The questions is if we need a useful subset of 4.2 to bother.
>
> Internally the virtualization people have been interested in ALLOCATE,
> SEEK, and security labels, so I'm assuming we've passed that sort of
> minimum "is there any benefit at all to turning this on" threshhold.
ACK. There is client support for that functionality that hooks into
well established system calls, which means that applications can use
it now without much in the way of changes (if at all).
>> I doubt we'll ever bother with ADBs for example, and the copy offload
>> might take a while to get everyting sorted. But exposting most
>> attributes and supporting READ_PLUS sounds like important enought to
>> implement before considering 4.2 ready.
>
> I agree there's a documentation and marketing problem: it would simplify
> communication with users if "this server supports 4.2" reliably meant
> support for some minimum list of features. Is that what you're thinking
> about?
None of our NFSv4 versions are 100% feature complete. Our approach on
both the client and server has been to take the functionality that is
useful to us and implement that first.
For instance, NFSv4.1 is still missing RPCSEC_GSS on the callback
channel. I do want to implement that feature some day, but that
doesn't stop me from considering NFSv4.1 to be useful in the state it
is today.
> Individual distros and other server vendors may make their own decisions
> here, so I don't know if we do much about that on our own.
>
> We could also add a little more data e.g. to /proc/self/mountstats to
> help figure out stuff like "why does copying a big file go so much
> faster on server X than server Y?".
We already have that information. As we add new RPC calls on the
client, we add corresponding entries in /proc/self/mountstats. When
copy offload goes in, it will have its own entry there, and you will
see the usage counts being bumped whenever an application calls it.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On Wed, Feb 11, 2015 at 10:15:43AM -0500, Trond Myklebust wrote:
> On Wed, Feb 11, 2015 at 9:54 AM, J. Bruce Fields <[email protected]> wrote:
> > On Wed, Feb 11, 2015 at 06:16:19AM -0800, Christoph Hellwig wrote:
> >> On Wed, Feb 11, 2015 at 09:12:57AM -0500, J. Bruce Fields wrote:
> >> > I think so. That's all optional--e.g. for READ_PLUS clients can
> >> > determine server support using ERR_OP_NOTSUPP (or whatever it's called),
> >> > and for attributes they can query the supported_attributes attribute.
> >> > It's possible we'll never support everything in 4.2.
> >>
> >> The questions is if we need a useful subset of 4.2 to bother.
> >
> > Internally the virtualization people have been interested in ALLOCATE,
> > SEEK, and security labels, so I'm assuming we've passed that sort of
> > minimum "is there any benefit at all to turning this on" threshhold.
>
> ACK. There is client support for that functionality that hooks into
> well established system calls, which means that applications can use
> it now without much in the way of changes (if at all).
>
> >> I doubt we'll ever bother with ADBs for example, and the copy offload
> >> might take a while to get everyting sorted. But exposting most
> >> attributes and supporting READ_PLUS sounds like important enought to
> >> implement before considering 4.2 ready.
> >
> > I agree there's a documentation and marketing problem: it would simplify
> > communication with users if "this server supports 4.2" reliably meant
> > support for some minimum list of features. Is that what you're thinking
> > about?
>
> None of our NFSv4 versions are 100% feature complete. Our approach on
> both the client and server has been to take the functionality that is
> useful to us and implement that first.
> For instance, NFSv4.1 is still missing RPCSEC_GSS on the callback
> channel. I do want to implement that feature some day, but that
> doesn't stop me from considering NFSv4.1 to be useful in the state it
> is today.
>
> > Individual distros and other server vendors may make their own decisions
> > here, so I don't know if we do much about that on our own.
> >
> > We could also add a little more data e.g. to /proc/self/mountstats to
> > help figure out stuff like "why does copying a big file go so much
> > faster on server X than server Y?".
>
> We already have that information. As we add new RPC calls on the
> client, we add corresponding entries in /proc/self/mountstats. When
> copy offload goes in, it will have its own entry there, and you will
> see the usage counts being bumped whenever an application calls it.
Oh, and looking now--I'd forgotten that we also support the
supported-attributes bitmaps.
Maybe that covers everything.
Someone could also add a server-side interface for querying features
like this if it seemed useful.
--b.
On Wed, Feb 11, 2015 at 09:54:13AM -0500, J. Bruce Fields wrote:
>
> I agree there's a documentation and marketing problem: it would simplify
> communication with users if "this server supports 4.2" reliably meant
> support for some minimum list of features.
>
The "marketing" message over NFSv4.2 has been pretty consistent - everything
is optional and a fully compliant server can return not supported for
every new feature. I.e., a NFSv4.2 server is pretty simple if you have
an existing NFSv4.1 server.
On Wed, Feb 11, 2015 at 10:12:31AM -0800, Tom Haynes wrote:
> On Wed, Feb 11, 2015 at 09:54:13AM -0500, J. Bruce Fields wrote:
> >
> > I agree there's a documentation and marketing problem: it would simplify
> > communication with users if "this server supports 4.2" reliably meant
> > support for some minimum list of features.
> >
>
> The "marketing" message over NFSv4.2 has been pretty consistent - everything
> is optional and a fully compliant server can return not supported for
> every new feature. I.e., a NFSv4.2 server is pretty simple if you have
> an existing NFSv4.1 server.
Yes, and I like that, but it's not without tradeoffs.
--b.