These patches implement just the SEEK NFS v4.2 operation. WRITE_PLUS is
still under discussion with the IETF after my last series of patches, so I
am holding off on resubmitting until after spec discussion dies down.
Questions? Comments? Thoughts?
Anna
Anna Schumaker (3):
NFSD: Update error codes
NFSD: Create nfs v4.2 decode ops
NFSD: Implement SEEK
fs/nfsd/nfs4proc.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++
fs/nfsd/nfs4xdr.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++
fs/nfsd/nfsd.h | 2 +-
fs/nfsd/xdr4.h | 16 +++++++++++++++
include/linux/nfs4.h | 23 ++++++++++++++++++---
5 files changed, 151 insertions(+), 4 deletions(-)
--
1.8.4.2
On Wed, Nov 13, 2013 at 5:49 PM, J. Bruce Fields <[email protected]> wrote:
> On Wed, Nov 13, 2013 at 08:15:27AM -0800, Christoph Hellwig wrote:
>> On Wed, Nov 13, 2013 at 11:07:19AM -0500, Anna Schumaker wrote:
>> > I'm thinking something like this:
>>
>> Given that the whole sparse file support seems more experimental than
>> the security labels requiring the former for the latter seems a bit odd.
>>
>> I have to admit that I don't really know how to deal with those changes,
>> on the one hand I'd love to expose it as soon as possible, on the other
>> hand the spec has so many higher level flaws related to their concepts
>> of sparse files that I'd feel really bad about locking even parts of it
>> in at the moment.
>
> This isn't a candidate for 3.13, and SEEK didn't look like the most
> problematic bit, so with a couple more months I'm hoping we'll be more
> confident about the protocol?
>
> Actually now that I look, I forget: even if security labels are built
> in, 4.2 is still off by default at runtime for now.
>
> We could add another interface to toggle individual features at run time
> but I think that's definitely too complicated.
>
> Maybe:
>
> - keep 4.2 off by default a runtime for now.
> - keep each feature under its individual config option:
> NFSD_V4_SECURITY_LABEL, NFSD_V4_SEEK, NFSD_V4_SEND_PONIES....
> - when an individual feature matures, ditch its config option
> and build it unconditionally. We're always getting little
> build bugs due to untested build options so I'd rather not
> keep them around indefinitely.
> - once 4.2 has at least one feature that we think is mature
> enough, switch the runtime 4.2 default to on and depend on
> scary warnings on the remaining build options to keep people
> from exposing them in production.
NFSD_V4_SEND_PONIES is mandatory for 3.13!!!!!
:)
Josh
On Tue, Nov 12, 2013 at 04:32:51PM -0800, Marc Eshel wrote:
> "J. Bruce Fields" <[email protected]> wrote on 11/12/2013 03:02:01 PM:
>
> > From: "J. Bruce Fields" <[email protected]>
> > To: Marc Eshel/Almaden/IBM@IBMUS,
> > Cc: Anna Schumaker <[email protected]>, [email protected],
> > [email protected]
> > Date: 11/12/2013 03:19 PM
> > Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK
> >
> > On Tue, Nov 12, 2013 at 02:44:21PM -0800, Marc Eshel wrote:
> > > [email protected] wrote on 11/12/2013 11:45:29 AM:
> > >
> > > > From: "J. Bruce Fields" <[email protected]>
> > > > To: Anna Schumaker <[email protected]>,
> > > > Cc: [email protected]
> > > > Date: 11/12/2013 12:07 PM
> > > > Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK
> > > > Sent by: [email protected]
> > > >
> > > > On Tue, Nov 12, 2013 at 02:04:05PM -0500, Anna Schumaker wrote:
> > > > > These patches implement just the SEEK NFS v4.2 operation.
> WRITE_PLUS
> > > is
> > > > > still under discussion with the IETF after my last series of
> patches,
> > > so I
> > > > > am holding off on resubmitting until after spec discussion dies
> down.
> > > > >
> > > > > Questions? Comments? Thoughts?
> > > > > Anna
> > > > >
> > > > > Anna Schumaker (3):
> > > > > NFSD: Update error codes
> > > >
> > > > I don't think I got this first patch.
> > > >
> > > > > NFSD: Create nfs v4.2 decode ops
> > > > > NFSD: Implement SEEK
> > > >
> > > > I'd like to be reassured the protocol is reasonably stable before we
> > > > commit this. I haven't been following the ietf wg discussion
> closely.
> > > >
> > > > And this should initially be disabled by default. So, probably
> either:
> > >
> > > It is not enough that it is usable only for client the mount
> > > minorversion=2
> > > anyone using this option knows that they are using a prototype.
> >
> > The client may default to minorversion=2 some day, so, no, the user
> > doesn't necessarily know they're using a prototype.
> >
> > And the server doesn't have any control over what kernel or distro the
> > client's running. We want future clients to be able to default to 4.2,
> > and we don't require servers and clients to be upgraded in lockstep.
>
> The server accepting 4.2 mount can be under config options but once it is
> mounted it can support the new features by checking for the the version,
> right?
Sorry, I don't understand the question.
--b.
Recent NFS v4.2 drafts have removed NFS4ERR_METADATA_NOTSUPP and
reassigned the error code to NFS4ERR_UNION_NOTSUPP.
Signed-off-by: Anna Schumaker <[email protected]>
---
fs/nfsd/nfsd.h | 2 +-
include/linux/nfs4.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/nfsd/nfsd.h b/fs/nfsd/nfsd.h
index 30f34ab..4fe49e9 100644
--- a/fs/nfsd/nfsd.h
+++ b/fs/nfsd/nfsd.h
@@ -244,7 +244,7 @@ void nfsd_lockd_shutdown(void);
#define nfserr_deleg_revoked cpu_to_be32(NFS4ERR_DELEG_REVOKED)
#define nfserr_partner_notsupp cpu_to_be32(NFS4ERR_PARTNER_NOTSUPP)
#define nfserr_partner_no_auth cpu_to_be32(NFS4ERR_PARTNER_NO_AUTH)
-#define nfserr_metadata_notsupp cpu_to_be32(NFS4ERR_METADATA_NOTSUPP)
+#define nfserr_union_notsupp cpu_to_be32(NFS4ERR_UNION_NOTSUPP)
#define nfserr_offload_denied cpu_to_be32(NFS4ERR_OFFLOAD_DENIED)
#define nfserr_wrong_lfs cpu_to_be32(NFS4ERR_WRONG_LFS)
#define nfserr_badlabel cpu_to_be32(NFS4ERR_BADLABEL)
diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h
index 9577769..6d79deb 100644
--- a/include/linux/nfs4.h
+++ b/include/linux/nfs4.h
@@ -235,7 +235,7 @@ enum nfsstat4 {
/* nfs42 */
NFS4ERR_PARTNER_NOTSUPP = 10088,
NFS4ERR_PARTNER_NO_AUTH = 10089,
- NFS4ERR_METADATA_NOTSUPP = 10090,
+ NFS4ERR_UNION_NOTSUPP = 10090,
NFS4ERR_OFFLOAD_DENIED = 10091,
NFS4ERR_WRONG_LFS = 10092,
NFS4ERR_BADLABEL = 10093,
--
1.8.4.2
On 11/13/2013 11:49 AM, J. Bruce Fields wrote:
> On Wed, Nov 13, 2013 at 08:15:27AM -0800, Christoph Hellwig wrote:
>> On Wed, Nov 13, 2013 at 11:07:19AM -0500, Anna Schumaker wrote:
>>> I'm thinking something like this:
>>
>> Given that the whole sparse file support seems more experimental than
>> the security labels requiring the former for the latter seems a bit odd.
>>
>> I have to admit that I don't really know how to deal with those changes,
>> on the one hand I'd love to expose it as soon as possible, on the other
>> hand the spec has so many higher level flaws related to their concepts
>> of sparse files that I'd feel really bad about locking even parts of it
>> in at the moment.
>
> This isn't a candidate for 3.13, and SEEK didn't look like the most
> problematic bit, so with a couple more months I'm hoping we'll be more
> confident about the protocol?
>
> Actually now that I look, I forget: even if security labels are built
> in, 4.2 is still off by default at runtime for now.
>
> We could add another interface to toggle individual features at run time
> but I think that's definitely too complicated.
>
> Maybe:
>
> - keep 4.2 off by default a runtime for now.
> - keep each feature under its individual config option:
> NFSD_V4_SECURITY_LABEL, NFSD_V4_SEEK, NFSD_V4_SEND_PONIES....
> - when an individual feature matures, ditch its config option
> and build it unconditionally. We're always getting little
> build bugs due to untested build options so I'd rather not
> keep them around indefinitely.
> - once 4.2 has at least one feature that we think is mature
> enough, switch the runtime 4.2 default to on and depend on
> scary warnings on the remaining build options to keep people
> from exposing them in production.
>
> ?
That's doable too. And it keeps me from having to touch security label code that I don't know a whole lot about!
Anna
>
> --b.
>
"J. Bruce Fields" <[email protected]> wrote on 11/12/2013 03:02:01 PM:
> From: "J. Bruce Fields" <[email protected]>
> To: Marc Eshel/Almaden/IBM@IBMUS,
> Cc: Anna Schumaker <[email protected]>, [email protected],
> [email protected]
> Date: 11/12/2013 03:19 PM
> Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK
>
> On Tue, Nov 12, 2013 at 02:44:21PM -0800, Marc Eshel wrote:
> > [email protected] wrote on 11/12/2013 11:45:29 AM:
> >
> > > From: "J. Bruce Fields" <[email protected]>
> > > To: Anna Schumaker <[email protected]>,
> > > Cc: [email protected]
> > > Date: 11/12/2013 12:07 PM
> > > Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK
> > > Sent by: [email protected]
> > >
> > > On Tue, Nov 12, 2013 at 02:04:05PM -0500, Anna Schumaker wrote:
> > > > These patches implement just the SEEK NFS v4.2 operation.
WRITE_PLUS
> > is
> > > > still under discussion with the IETF after my last series of
patches,
> > so I
> > > > am holding off on resubmitting until after spec discussion dies
down.
> > > >
> > > > Questions? Comments? Thoughts?
> > > > Anna
> > > >
> > > > Anna Schumaker (3):
> > > > NFSD: Update error codes
> > >
> > > I don't think I got this first patch.
> > >
> > > > NFSD: Create nfs v4.2 decode ops
> > > > NFSD: Implement SEEK
> > >
> > > I'd like to be reassured the protocol is reasonably stable before we
> > > commit this. I haven't been following the ietf wg discussion
closely.
> > >
> > > And this should initially be disabled by default. So, probably
either:
> >
> > It is not enough that it is usable only for client the mount
> > minorversion=2
> > anyone using this option knows that they are using a prototype.
>
> The client may default to minorversion=2 some day, so, no, the user
> doesn't necessarily know they're using a prototype.
>
> And the server doesn't have any control over what kernel or distro the
> client's running. We want future clients to be able to default to 4.2,
> and we don't require servers and clients to be upgraded in lockstep.
The server accepting 4.2 mount can be under config options but once it is
mounted it can support the new features by checking for the the version,
right?
Marc.
>
> --b.
>
[email protected] wrote on 11/12/2013 11:45:29 AM:
> From: "J. Bruce Fields" <[email protected]>
> To: Anna Schumaker <[email protected]>,
> Cc: [email protected]
> Date: 11/12/2013 12:07 PM
> Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK
> Sent by: [email protected]
>
> On Tue, Nov 12, 2013 at 02:04:05PM -0500, Anna Schumaker wrote:
> > These patches implement just the SEEK NFS v4.2 operation. WRITE_PLUS
is
> > still under discussion with the IETF after my last series of patches,
so I
> > am holding off on resubmitting until after spec discussion dies down.
> >
> > Questions? Comments? Thoughts?
> > Anna
> >
> > Anna Schumaker (3):
> > NFSD: Update error codes
>
> I don't think I got this first patch.
>
> > NFSD: Create nfs v4.2 decode ops
> > NFSD: Implement SEEK
>
> I'd like to be reassured the protocol is reasonably stable before we
> commit this. I haven't been following the ietf wg discussion closely.
>
> And this should initially be disabled by default. So, probably either:
It is not enough that it is usable only for client the mount
minorversion=2
anyone using this option knows that they are using a prototype.
Marc.
>
> - Introduce a new NFSD_V4_SEEK option, or
> - Combine this and NFSD_V4_SECURITY_LABEL and this into a single
> NFSD_V4_2 option.
>
> And recommend "N" for now.
>
> Probably the latter I guess, to be consistent with the client. And
> because otherwise we could end up with an awful lot of config options.
>
> --b.
>
> >
> > fs/nfsd/nfs4proc.c | 56 +++++++++++++++++++++++++++++++++++++++
> +++++++++++
> > fs/nfsd/nfs4xdr.c | 58 +++++++++++++++++++++++++++++++++++++++
> +++++++++++++
> > fs/nfsd/nfsd.h | 2 +-
> > fs/nfsd/xdr4.h | 16 +++++++++++++++
> > include/linux/nfs4.h | 23 ++++++++++++++++++---
> > 5 files changed, 151 insertions(+), 4 deletions(-)
> >
> > --
> > 1.8.4.2
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On 11/12/2013 02:59 PM, J. Bruce Fields wrote:
> On Tue, Nov 12, 2013 at 02:54:15PM -0500, Anna Schumaker wrote:
>> On 11/12/2013 02:45 PM, J. Bruce Fields wrote:
>>> On Tue, Nov 12, 2013 at 02:04:05PM -0500, Anna Schumaker wrote:
>>>> These patches implement just the SEEK NFS v4.2 operation. WRITE_PLUS is
>>>> still under discussion with the IETF after my last series of patches, so I
>>>> am holding off on resubmitting until after spec discussion dies down.
>>>>
>>>> Questions? Comments? Thoughts?
>>>> Anna
>>>>
>>>> Anna Schumaker (3):
>>>> NFSD: Update error codes
>>>
>>> I don't think I got this first patch.
>>
>> It's in the "patches" directory I used, but I don't see it in my gmail inbox either. I'll send it out in a minute.
>>
>>>
>>>> NFSD: Create nfs v4.2 decode ops
>>>> NFSD: Implement SEEK
>>>
>>> I'd like to be reassured the protocol is reasonably stable before we
>>> commit this. I haven't been following the ietf wg discussion closely.
>>>
>>> And this should initially be disabled by default. So, probably either:
>>>
>>> - Introduce a new NFSD_V4_SEEK option, or
>>> - Combine this and NFSD_V4_SECURITY_LABEL and this into a single
>>> NFSD_V4_2 option.
>>>
>>> And recommend "N" for now.
>>>
>>> Probably the latter I guess, to be consistent with the client. And
>>> because otherwise we could end up with an awful lot of config options.
>>
>> Sure, I can do that easily enough.
>
> OK. In that case, you'll probably want to do an additional patch at the
> beginning just to replace NFSD_V4_SECURITY_LABEL by NFSD_V4_2. Note
> it's not a pure search-and-replace since the latter covers a little more
> code.
Would you accept a patch that instead introduces CONFIG_NFSD_V4_2 and then makes the security label depend on that config option?
>
> The only thing that worries me a bit is the features may mature at
> different times. I guess when the time comes we could split it into
> NFSD_V4_2 and NFSD_V4_2_EXPERIMENTAL and recommend distros and
> non-developers turn on only the former?
>
> --b.
>
On 11/12/2013 02:45 PM, J. Bruce Fields wrote:
> On Tue, Nov 12, 2013 at 02:04:05PM -0500, Anna Schumaker wrote:
>> These patches implement just the SEEK NFS v4.2 operation. WRITE_PLUS is
>> still under discussion with the IETF after my last series of patches, so I
>> am holding off on resubmitting until after spec discussion dies down.
>>
>> Questions? Comments? Thoughts?
>> Anna
>>
>> Anna Schumaker (3):
>> NFSD: Update error codes
>
> I don't think I got this first patch.
It's in the "patches" directory I used, but I don't see it in my gmail inbox either. I'll send it out in a minute.
>
>> NFSD: Create nfs v4.2 decode ops
>> NFSD: Implement SEEK
>
> I'd like to be reassured the protocol is reasonably stable before we
> commit this. I haven't been following the ietf wg discussion closely.
>
> And this should initially be disabled by default. So, probably either:
>
> - Introduce a new NFSD_V4_SEEK option, or
> - Combine this and NFSD_V4_SECURITY_LABEL and this into a single
> NFSD_V4_2 option.
>
> And recommend "N" for now.
>
> Probably the latter I guess, to be consistent with the client. And
> because otherwise we could end up with an awful lot of config options.
Sure, I can do that easily enough.
Anna
>
> --b.
>
>>
>> fs/nfsd/nfs4proc.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> fs/nfsd/nfs4xdr.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> fs/nfsd/nfsd.h | 2 +-
>> fs/nfsd/xdr4.h | 16 +++++++++++++++
>> include/linux/nfs4.h | 23 ++++++++++++++++++---
>> 5 files changed, 151 insertions(+), 4 deletions(-)
>>
>> --
>> 1.8.4.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
This patch adds in the SEEK operation used by clients doing an llseek on
a file to find either hole or data segments. I am making the assumption
that allocated == true in the NFS4_CONTENT_DATA case and false for the
NFS4_CONTENT_HOLE case.
Signed-off-by: Anna Schumaker <[email protected]>
---
Changed in V2:
- Handle the NFS4_CONTENT_APP_DATA_HOLE case
- Return error codes provided by nfserrno()
fs/nfsd/nfs4proc.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++
fs/nfsd/nfs4xdr.c | 40 +++++++++++++++++++++++++++++++++++--
fs/nfsd/xdr4.h | 16 +++++++++++++++
include/linux/nfs4.h | 6 ++++++
4 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index 419572f..a82021c 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1028,6 +1028,57 @@ nfsd4_write(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
return status;
}
+static __be32
+nfsd4_seek(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
+ struct nfsd4_seek *seek)
+{
+ struct file *file;
+ loff_t end_pos = 0;
+ __be32 status;
+
+ nfs4_lock_state();
+ status = nfs4_preprocess_stateid_op(SVC_NET(rqstp), cstate,
+ &seek->seek_stateid,
+ RD_STATE | WR_STATE, &file);
+ if (status != nfs_ok) {
+ nfs4_unlock_state();
+ return status;
+ } else
+ get_file(file);
+ nfs4_unlock_state();
+
+ switch (seek->seek_whence) {
+ case NFS4_CONTENT_APP_DATA_HOLE:
+ status = nfserr_union_notsupp;
+ break;
+ case NFS4_CONTENT_DATA:
+ seek->seek_pos = vfs_llseek(file, seek->seek_offset, SEEK_DATA);
+ end_pos = vfs_llseek(file, seek->seek_pos, SEEK_HOLE);
+ seek->seek_allocated = true;
+ break;
+ case NFS4_CONTENT_HOLE:
+ seek->seek_pos = vfs_llseek(file, seek->seek_offset, SEEK_HOLE);
+ end_pos = vfs_llseek(file, seek->seek_pos, SEEK_DATA);
+ seek->seek_allocated = false;
+ break;
+ default:
+ status = nfs_ok;
+ seek->seek_eof = true;
+ goto out;
+ }
+
+ if (seek->seek_pos < 0) {
+ status = nfserrno(seek->seek_pos);
+ goto out;
+ }
+
+ seek->seek_length = end_pos - seek->seek_pos;
+
+out:
+ fput(file);
+ return status;
+}
+
/* This routine never returns NFS_OK! If there are no other errors, it
* will return NFSERR_SAME or NFSERR_NOT_SAME depending on whether the
* attributes matched. VERIFY is implemented by mapping NFSERR_SAME
@@ -1840,6 +1891,11 @@ static struct nfsd4_operation nfsd4_ops[] = {
.op_get_currentstateid = (stateid_getter)nfsd4_get_freestateid,
.op_rsize_bop = (nfsd4op_rsize)nfsd4_only_status_rsize,
},
+
+ [OP_SEEK] = {
+ .op_func = (nfsd4op_func)nfsd4_seek,
+ .op_name = "OP_SEEK",
+ },
};
#ifdef NFSD_DEBUG
diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index 3af6c46..45ad9ec 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -1508,6 +1508,22 @@ static __be32 nfsd4_decode_reclaim_complete(struct nfsd4_compoundargs *argp, str
}
static __be32
+nfsd4_decode_seek(struct nfsd4_compoundargs *argp, struct nfsd4_seek *seek)
+{
+ DECODE_HEAD;
+
+ status = nfsd4_decode_stateid(argp, &seek->seek_stateid);
+ if (status)
+ return status;
+
+ READ_BUF(12);
+ READ64(seek->seek_offset);
+ READ32(seek->seek_whence);
+
+ DECODE_TAIL;
+}
+
+static __be32
nfsd4_decode_noop(struct nfsd4_compoundargs *argp, void *p)
{
return nfs_ok;
@@ -1589,7 +1605,7 @@ static nfsd4_dec nfsd4_dec_ops[] = {
[OP_OFFLOAD_STATUS] = (nfsd4_dec)nfsd4_decode_notsupp,
[OP_WRITE_PLUS] = (nfsd4_dec)nfsd4_decode_notsupp,
[OP_READ_PLUS] = (nfsd4_dec)nfsd4_decode_notsupp,
- [OP_SEEK] = (nfsd4_dec)nfsd4_decode_notsupp,
+ [OP_SEEK] = (nfsd4_dec)nfsd4_decode_seek,
[OP_IO_ADVISE] = (nfsd4_dec)nfsd4_decode_notsupp,
};
@@ -3515,6 +3531,26 @@ nfsd4_encode_test_stateid(struct nfsd4_compoundres *resp, __be32 nfserr,
}
static __be32
+nfsd4_encode_seek(struct nfsd4_compoundres *resp, __be32 nfserr,
+ struct nfsd4_seek *seek)
+{
+ __be32 *p;
+
+ if (nfserr)
+ return nfserr;
+
+ RESERVE_SPACE(28);
+ WRITE32(seek->seek_eof);
+ WRITE32(seek->seek_whence);
+ WRITE64(seek->seek_pos);
+ WRITE64(seek->seek_length);
+ WRITE32(seek->seek_allocated);
+ ADJUST_ARGS();
+
+ return nfserr;
+}
+
+static __be32
nfsd4_encode_noop(struct nfsd4_compoundres *resp, __be32 nfserr, void *p)
{
return nfserr;
@@ -3595,7 +3631,7 @@ static nfsd4_enc nfsd4_enc_ops[] = {
[OP_OFFLOAD_STATUS] = (nfsd4_enc)nfsd4_encode_noop,
[OP_WRITE_PLUS] = (nfsd4_enc)nfsd4_encode_noop,
[OP_READ_PLUS] = (nfsd4_enc)nfsd4_encode_noop,
- [OP_SEEK] = (nfsd4_enc)nfsd4_encode_noop,
+ [OP_SEEK] = (nfsd4_enc)nfsd4_encode_seek,
[OP_IO_ADVISE] = (nfsd4_enc)nfsd4_encode_noop,
};
diff --git a/fs/nfsd/xdr4.h b/fs/nfsd/xdr4.h
index b3ed644..c2f4e30 100644
--- a/fs/nfsd/xdr4.h
+++ b/fs/nfsd/xdr4.h
@@ -430,6 +430,19 @@ struct nfsd4_reclaim_complete {
u32 rca_one_fs;
};
+struct nfsd4_seek {
+ /* request */
+ stateid_t seek_stateid;
+ loff_t seek_offset;
+ u32 seek_whence;
+
+ /* response */
+ u64 seek_pos;
+ u32 seek_eof;
+ u64 seek_length;
+ u32 seek_allocated;
+};
+
struct nfsd4_op {
int opnum;
__be32 status;
@@ -475,6 +488,9 @@ struct nfsd4_op {
struct nfsd4_reclaim_complete reclaim_complete;
struct nfsd4_test_stateid test_stateid;
struct nfsd4_free_stateid free_stateid;
+
+ /* NFSv4.2 */
+ struct nfsd4_seek seek;
} u;
struct nfs4_replay * replay;
};
diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h
index 01119ed..144f511 100644
--- a/include/linux/nfs4.h
+++ b/include/linux/nfs4.h
@@ -556,4 +556,10 @@ struct nfs4_deviceid {
char data[NFS4_DEVICEID4_SIZE];
};
+enum data_content4 {
+ NFS4_CONTENT_DATA = 0,
+ NFS4_CONTENT_APP_DATA_HOLE = 1,
+ NFS4_CONTENT_HOLE = 2,
+};
+
#endif
--
1.8.4.2
On Wed, Nov 13, 2013 at 08:15:27AM -0800, Christoph Hellwig wrote:
> On Wed, Nov 13, 2013 at 11:07:19AM -0500, Anna Schumaker wrote:
> > I'm thinking something like this:
>
> Given that the whole sparse file support seems more experimental than
> the security labels requiring the former for the latter seems a bit odd.
>
> I have to admit that I don't really know how to deal with those changes,
> on the one hand I'd love to expose it as soon as possible, on the other
> hand the spec has so many higher level flaws related to their concepts
> of sparse files that I'd feel really bad about locking even parts of it
> in at the moment.
This isn't a candidate for 3.13, and SEEK didn't look like the most
problematic bit, so with a couple more months I'm hoping we'll be more
confident about the protocol?
Actually now that I look, I forget: even if security labels are built
in, 4.2 is still off by default at runtime for now.
We could add another interface to toggle individual features at run time
but I think that's definitely too complicated.
Maybe:
- keep 4.2 off by default a runtime for now.
- keep each feature under its individual config option:
NFSD_V4_SECURITY_LABEL, NFSD_V4_SEEK, NFSD_V4_SEND_PONIES....
- when an individual feature matures, ditch its config option
and build it unconditionally. We're always getting little
build bugs due to untested build options so I'd rather not
keep them around indefinitely.
- once 4.2 has at least one feature that we think is mature
enough, switch the runtime 4.2 default to on and depend on
scary warnings on the remaining build options to keep people
from exposing them in production.
?
--b.
On Tue, Nov 12, 2013 at 02:54:15PM -0500, Anna Schumaker wrote:
> On 11/12/2013 02:45 PM, J. Bruce Fields wrote:
> > On Tue, Nov 12, 2013 at 02:04:05PM -0500, Anna Schumaker wrote:
> >> These patches implement just the SEEK NFS v4.2 operation. WRITE_PLUS is
> >> still under discussion with the IETF after my last series of patches, so I
> >> am holding off on resubmitting until after spec discussion dies down.
> >>
> >> Questions? Comments? Thoughts?
> >> Anna
> >>
> >> Anna Schumaker (3):
> >> NFSD: Update error codes
> >
> > I don't think I got this first patch.
>
> It's in the "patches" directory I used, but I don't see it in my gmail inbox either. I'll send it out in a minute.
>
> >
> >> NFSD: Create nfs v4.2 decode ops
> >> NFSD: Implement SEEK
> >
> > I'd like to be reassured the protocol is reasonably stable before we
> > commit this. I haven't been following the ietf wg discussion closely.
> >
> > And this should initially be disabled by default. So, probably either:
> >
> > - Introduce a new NFSD_V4_SEEK option, or
> > - Combine this and NFSD_V4_SECURITY_LABEL and this into a single
> > NFSD_V4_2 option.
> >
> > And recommend "N" for now.
> >
> > Probably the latter I guess, to be consistent with the client. And
> > because otherwise we could end up with an awful lot of config options.
>
> Sure, I can do that easily enough.
OK. In that case, you'll probably want to do an additional patch at the
beginning just to replace NFSD_V4_SECURITY_LABEL by NFSD_V4_2. Note
it's not a pure search-and-replace since the latter covers a little more
code.
The only thing that worries me a bit is the features may mature at
different times. I guess when the time comes we could split it into
NFSD_V4_2 and NFSD_V4_2_EXPERIMENTAL and recommend distros and
non-developers turn on only the former?
--b.
where do you see this change?, the last version 20 don't show it.
Thanks, Marc.
From: Anna Schumaker <[email protected]>
To: Anna Schumaker <[email protected]>, [email protected],
[email protected],
Date: 11/12/2013 12:50 PM
Subject: [PATCH v2 1/3] NFSD: Update error codes
Sent by: [email protected]
Recent NFS v4.2 drafts have removed NFS4ERR_METADATA_NOTSUPP and
reassigned the error code to NFS4ERR_UNION_NOTSUPP.
Signed-off-by: Anna Schumaker <[email protected]>
---
fs/nfsd/nfsd.h | 2 +-
include/linux/nfs4.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/nfsd/nfsd.h b/fs/nfsd/nfsd.h
index 30f34ab..4fe49e9 100644
--- a/fs/nfsd/nfsd.h
+++ b/fs/nfsd/nfsd.h
@@ -244,7 +244,7 @@ void nfsd_lockd_shutdown(void);
#define nfserr_deleg_revoked cpu_to_be32(NFS4ERR_DELEG_REVOKED)
#define nfserr_partner_notsupp cpu_to_be32(NFS4ERR_PARTNER_NOTSUPP)
#define nfserr_partner_no_auth cpu_to_be32(NFS4ERR_PARTNER_NO_AUTH)
-#define nfserr_metadata_notsupp cpu_to_be32(NFS4ERR_METADATA_NOTSUPP)
+#define nfserr_union_notsupp cpu_to_be32(NFS4ERR_UNION_NOTSUPP)
#define nfserr_offload_denied cpu_to_be32(NFS4ERR_OFFLOAD_DENIED)
#define nfserr_wrong_lfs cpu_to_be32(NFS4ERR_WRONG_LFS)
#define nfserr_badlabel cpu_to_be32(NFS4ERR_BADLABEL)
diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h
index 9577769..6d79deb 100644
--- a/include/linux/nfs4.h
+++ b/include/linux/nfs4.h
@@ -235,7 +235,7 @@ enum nfsstat4 {
/* nfs42 */
NFS4ERR_PARTNER_NOTSUPP = 10088,
NFS4ERR_PARTNER_NO_AUTH = 10089,
- NFS4ERR_METADATA_NOTSUPP = 10090,
+ NFS4ERR_UNION_NOTSUPP = 10090,
NFS4ERR_OFFLOAD_DENIED = 10091,
NFS4ERR_WRONG_LFS = 10092,
NFS4ERR_BADLABEL = 10093,
--
1.8.4.2
On Tue, Nov 12, 2013 at 02:44:21PM -0800, Marc Eshel wrote:
> [email protected] wrote on 11/12/2013 11:45:29 AM:
>
> > From: "J. Bruce Fields" <[email protected]>
> > To: Anna Schumaker <[email protected]>,
> > Cc: [email protected]
> > Date: 11/12/2013 12:07 PM
> > Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK
> > Sent by: [email protected]
> >
> > On Tue, Nov 12, 2013 at 02:04:05PM -0500, Anna Schumaker wrote:
> > > These patches implement just the SEEK NFS v4.2 operation. WRITE_PLUS
> is
> > > still under discussion with the IETF after my last series of patches,
> so I
> > > am holding off on resubmitting until after spec discussion dies down.
> > >
> > > Questions? Comments? Thoughts?
> > > Anna
> > >
> > > Anna Schumaker (3):
> > > NFSD: Update error codes
> >
> > I don't think I got this first patch.
> >
> > > NFSD: Create nfs v4.2 decode ops
> > > NFSD: Implement SEEK
> >
> > I'd like to be reassured the protocol is reasonably stable before we
> > commit this. I haven't been following the ietf wg discussion closely.
> >
> > And this should initially be disabled by default. So, probably either:
>
> It is not enough that it is usable only for client the mount
> minorversion=2
> anyone using this option knows that they are using a prototype.
The client may default to minorversion=2 some day, so, no, the user
doesn't necessarily know they're using a prototype.
And the server doesn't have any control over what kernel or distro the
client's running. We want future clients to be able to default to 4.2,
and we don't require servers and clients to be upgraded in lockstep.
--b.
On Wed, Nov 13, 2013 at 11:07:19AM -0500, Anna Schumaker wrote:
> I'm thinking something like this:
Given that the whole sparse file support seems more experimental than
the security labels requiring the former for the latter seems a bit odd.
I have to admit that I don't really know how to deal with those changes,
on the one hand I'd love to expose it as soon as possible, on the other
hand the spec has so many higher level flaws related to their concepts
of sparse files that I'd feel really bad about locking even parts of it
in at the moment.
On Tue, Nov 12, 2013 at 02:04:05PM -0500, Anna Schumaker wrote:
> These patches implement just the SEEK NFS v4.2 operation. WRITE_PLUS is
> still under discussion with the IETF after my last series of patches, so I
> am holding off on resubmitting until after spec discussion dies down.
>
> Questions? Comments? Thoughts?
> Anna
>
> Anna Schumaker (3):
> NFSD: Update error codes
I don't think I got this first patch.
> NFSD: Create nfs v4.2 decode ops
> NFSD: Implement SEEK
I'd like to be reassured the protocol is reasonably stable before we
commit this. I haven't been following the ietf wg discussion closely.
And this should initially be disabled by default. So, probably either:
- Introduce a new NFSD_V4_SEEK option, or
- Combine this and NFSD_V4_SECURITY_LABEL and this into a single
NFSD_V4_2 option.
And recommend "N" for now.
Probably the latter I guess, to be consistent with the client. And
because otherwise we could end up with an awful lot of config options.
--b.
>
> fs/nfsd/nfs4proc.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++
> fs/nfsd/nfs4xdr.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> fs/nfsd/nfsd.h | 2 +-
> fs/nfsd/xdr4.h | 16 +++++++++++++++
> include/linux/nfs4.h | 23 ++++++++++++++++++---
> 5 files changed, 151 insertions(+), 4 deletions(-)
>
> --
> 1.8.4.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Recent NFS v4.2 drafts have removed NFS4ERR_METADATA_NOTSUPP and
reassigned the error code to NFS4ERR_UNION_NOTSUPP.
Signed-off-by: Anna Schumaker <[email protected]>
---
fs/nfsd/nfsd.h | 2 +-
include/linux/nfs4.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/nfsd/nfsd.h b/fs/nfsd/nfsd.h
index 30f34ab..4fe49e9 100644
--- a/fs/nfsd/nfsd.h
+++ b/fs/nfsd/nfsd.h
@@ -244,7 +244,7 @@ void nfsd_lockd_shutdown(void);
#define nfserr_deleg_revoked cpu_to_be32(NFS4ERR_DELEG_REVOKED)
#define nfserr_partner_notsupp cpu_to_be32(NFS4ERR_PARTNER_NOTSUPP)
#define nfserr_partner_no_auth cpu_to_be32(NFS4ERR_PARTNER_NO_AUTH)
-#define nfserr_metadata_notsupp cpu_to_be32(NFS4ERR_METADATA_NOTSUPP)
+#define nfserr_union_notsupp cpu_to_be32(NFS4ERR_UNION_NOTSUPP)
#define nfserr_offload_denied cpu_to_be32(NFS4ERR_OFFLOAD_DENIED)
#define nfserr_wrong_lfs cpu_to_be32(NFS4ERR_WRONG_LFS)
#define nfserr_badlabel cpu_to_be32(NFS4ERR_BADLABEL)
diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h
index 9577769..6d79deb 100644
--- a/include/linux/nfs4.h
+++ b/include/linux/nfs4.h
@@ -235,7 +235,7 @@ enum nfsstat4 {
/* nfs42 */
NFS4ERR_PARTNER_NOTSUPP = 10088,
NFS4ERR_PARTNER_NO_AUTH = 10089,
- NFS4ERR_METADATA_NOTSUPP = 10090,
+ NFS4ERR_UNION_NOTSUPP = 10090,
NFS4ERR_OFFLOAD_DENIED = 10091,
NFS4ERR_WRONG_LFS = 10092,
NFS4ERR_BADLABEL = 10093,
--
1.8.4.2
It's cleaner to introduce everything at once and have the server reply
with "not supported" than it would be to introduce extra operations when
implementing a specific one in the middle of the list.
Signed-off-by: Anna Schumaker <[email protected]>
---
fs/nfsd/nfs4xdr.c | 22 ++++++++++++++++++++++
include/linux/nfs4.h | 15 +++++++++++++--
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index 83db5a7..3af6c46 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -1580,6 +1580,17 @@ static nfsd4_dec nfsd4_dec_ops[] = {
[OP_WANT_DELEGATION] = (nfsd4_dec)nfsd4_decode_notsupp,
[OP_DESTROY_CLIENTID] = (nfsd4_dec)nfsd4_decode_destroy_clientid,
[OP_RECLAIM_COMPLETE] = (nfsd4_dec)nfsd4_decode_reclaim_complete,
+
+ /* new operations for NFSv4.2 */
+ [OP_COPY] = (nfsd4_dec)nfsd4_decode_notsupp,
+ [OP_OFFLOAD_ABORT] = (nfsd4_dec)nfsd4_decode_notsupp,
+ [OP_COPY_NOTIFY] = (nfsd4_dec)nfsd4_decode_notsupp,
+ [OP_OFFLOAD_REVOKE] = (nfsd4_dec)nfsd4_decode_notsupp,
+ [OP_OFFLOAD_STATUS] = (nfsd4_dec)nfsd4_decode_notsupp,
+ [OP_WRITE_PLUS] = (nfsd4_dec)nfsd4_decode_notsupp,
+ [OP_READ_PLUS] = (nfsd4_dec)nfsd4_decode_notsupp,
+ [OP_SEEK] = (nfsd4_dec)nfsd4_decode_notsupp,
+ [OP_IO_ADVISE] = (nfsd4_dec)nfsd4_decode_notsupp,
};
static inline bool
@@ -3575,6 +3586,17 @@ static nfsd4_enc nfsd4_enc_ops[] = {
[OP_WANT_DELEGATION] = (nfsd4_enc)nfsd4_encode_noop,
[OP_DESTROY_CLIENTID] = (nfsd4_enc)nfsd4_encode_noop,
[OP_RECLAIM_COMPLETE] = (nfsd4_enc)nfsd4_encode_noop,
+
+ /* NFSv4.2 operations */
+ [OP_COPY] = (nfsd4_enc)nfsd4_encode_noop,
+ [OP_OFFLOAD_ABORT] = (nfsd4_enc)nfsd4_encode_noop,
+ [OP_COPY_NOTIFY] = (nfsd4_enc)nfsd4_encode_noop,
+ [OP_OFFLOAD_REVOKE] = (nfsd4_enc)nfsd4_encode_noop,
+ [OP_OFFLOAD_STATUS] = (nfsd4_enc)nfsd4_encode_noop,
+ [OP_WRITE_PLUS] = (nfsd4_enc)nfsd4_encode_noop,
+ [OP_READ_PLUS] = (nfsd4_enc)nfsd4_encode_noop,
+ [OP_SEEK] = (nfsd4_enc)nfsd4_encode_noop,
+ [OP_IO_ADVISE] = (nfsd4_enc)nfsd4_encode_noop,
};
/*
diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h
index 6d79deb..01119ed 100644
--- a/include/linux/nfs4.h
+++ b/include/linux/nfs4.h
@@ -110,6 +110,17 @@ enum nfs_opnum4 {
OP_DESTROY_CLIENTID = 57,
OP_RECLAIM_COMPLETE = 58,
+ /* nfs42 */
+ OP_COPY = 59,
+ OP_OFFLOAD_ABORT = 60,
+ OP_COPY_NOTIFY = 61,
+ OP_OFFLOAD_REVOKE = 62,
+ OP_OFFLOAD_STATUS = 63,
+ OP_WRITE_PLUS = 64,
+ OP_READ_PLUS = 65,
+ OP_SEEK = 66,
+ OP_IO_ADVISE = 67,
+
OP_ILLEGAL = 10044,
};
@@ -117,10 +128,10 @@ enum nfs_opnum4 {
Needs to be updated if more operations are defined in future.*/
#define FIRST_NFS4_OP OP_ACCESS
-#define LAST_NFS4_OP OP_RECLAIM_COMPLETE
+#define LAST_NFS4_OP OP_IO_ADVISE
#define LAST_NFS40_OP OP_RELEASE_LOCKOWNER
#define LAST_NFS41_OP OP_RECLAIM_COMPLETE
-#define LAST_NFS42_OP OP_RECLAIM_COMPLETE
+#define LAST_NFS42_OP OP_IO_ADVISE
enum nfsstat4 {
NFS4_OK = 0,
--
1.8.4.2
On Wed, Nov 13, 2013 at 11:49:59AM -0500, J. Bruce Fields wrote:
> This isn't a candidate for 3.13, and SEEK didn't look like the most
> problematic bit, so with a couple more months I'm hoping we'll be more
> confident about the protocol?
Wish I knew. The ieft list seems to be at an awfully small pace, and
the actual spec seems another layer separated from that. People who
are more familar with the process might have to chime in.
On Wed, Nov 13, 2013 at 08:52:04AM -0800, Christoph Hellwig wrote:
> On Wed, Nov 13, 2013 at 11:49:59AM -0500, J. Bruce Fields wrote:
> > This isn't a candidate for 3.13, and SEEK didn't look like the most
> > problematic bit, so with a couple more months I'm hoping we'll be more
> > confident about the protocol?
>
> Wish I knew. The ieft list seems to be at an awfully small pace,
It just varies depending on who's paying attention, I think. Tom's
actually been taking changes pretty quickly once there's patches.
> and the actual spec seems another layer separated from that. People
> who are more familar with the process might have to chime in.
Trond actually goes to those meetings on a regular basis, so he's
probably the one to chime in.
4.0 and 4.1 were both kind of huge and monolithic, and I don't remember
facing the problem of knowing when the specs were "done": the code
wasn't going to be ready before the rfc's were published anyway.
A lot of these 4.2 things look much simpler to implement, so now we've
got the option of releasing things into the wild before there's an rfc.
And if we screw up then we could end up sticking someone else with
behavior they don't want.
Better than specifying behavior that nobody wanted, which was more
likely before--it's good to be reviewing specs and patches at the same
time. But now I'm more vague on when to declare some part of the new
spec stable.
If there's no magic milestone then we just review and communicate as
best we can, I guess....
--b.
On 11/13/2013 11:01 AM, Anna Schumaker wrote:
> On 11/12/2013 02:59 PM, J. Bruce Fields wrote:
>> On Tue, Nov 12, 2013 at 02:54:15PM -0500, Anna Schumaker wrote:
>>> On 11/12/2013 02:45 PM, J. Bruce Fields wrote:
>>>> On Tue, Nov 12, 2013 at 02:04:05PM -0500, Anna Schumaker wrote:
>>>>> These patches implement just the SEEK NFS v4.2 operation. WRITE_PLUS is
>>>>> still under discussion with the IETF after my last series of patches, so I
>>>>> am holding off on resubmitting until after spec discussion dies down.
>>>>>
>>>>> Questions? Comments? Thoughts?
>>>>> Anna
>>>>>
>>>>> Anna Schumaker (3):
>>>>> NFSD: Update error codes
>>>>
>>>> I don't think I got this first patch.
>>>
>>> It's in the "patches" directory I used, but I don't see it in my gmail inbox either. I'll send it out in a minute.
>>>
>>>>
>>>>> NFSD: Create nfs v4.2 decode ops
>>>>> NFSD: Implement SEEK
>>>>
>>>> I'd like to be reassured the protocol is reasonably stable before we
>>>> commit this. I haven't been following the ietf wg discussion closely.
>>>>
>>>> And this should initially be disabled by default. So, probably either:
>>>>
>>>> - Introduce a new NFSD_V4_SEEK option, or
>>>> - Combine this and NFSD_V4_SECURITY_LABEL and this into a single
>>>> NFSD_V4_2 option.
>>>>
>>>> And recommend "N" for now.
>>>>
>>>> Probably the latter I guess, to be consistent with the client. And
>>>> because otherwise we could end up with an awful lot of config options.
>>>
>>> Sure, I can do that easily enough.
>>
>> OK. In that case, you'll probably want to do an additional patch at the
>> beginning just to replace NFSD_V4_SECURITY_LABEL by NFSD_V4_2. Note
>> it's not a pure search-and-replace since the latter covers a little more
>> code.
>
> Would you accept a patch that instead introduces CONFIG_NFSD_V4_2 and then makes the security label depend on that config option?
>
I'm thinking something like this:
diff --git a/fs/nfsd/Kconfig b/fs/nfsd/Kconfig
index dc8f1ef..5d0ca71 100644
--- a/fs/nfsd/Kconfig
+++ b/fs/nfsd/Kconfig
@@ -81,9 +81,18 @@ config NFSD_V4
If unsure, say N.
+config NFSD_V4_2
+ bool "Server support for NFS v4.2"
+ depends on NFSD_V4
+ help
+ This option enables support for minor version 2 of the NFSv4 protocol
+ in the kernel's NFS server.
+
+ If unsure, say N.
+
config NFSD_V4_SECURITY_LABEL
bool "Provide Security Label support for NFSv4 server"
- depends on NFSD_V4 && SECURITY
+ depends on NFSD_V4_2 && SECURITY
help
Say Y here if you want enable fine-grained security label attribute
>>
>> The only thing that worries me a bit is the features may mature at
>> different times. I guess when the time comes we could split it into
>> NFSD_V4_2 and NFSD_V4_2_EXPERIMENTAL and recommend distros and
>> non-developers turn on only the former?
>>
>> --b.
>>
>