[PATCH v2 0/3] NFSD: Implement SEEK

[PATCH v2 0/3] NFSD: Implement SEEK

[Anna Schumaker]

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

[PATCH v2 1/3] NFSD: Update error codes

[Anna Schumaker]

Recent NFS v4.2 drafts have removed NFS4ERR_METADATA_NOTSUPP and
reassigned the error code to NFS4ERR_UNION_NOTSUPP.

Signed-off-by: Anna Schumaker <bjschuma@netapp.com>
---
 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

[PATCH v2 2/3] NFSD: Create nfs v4.2 decode ops

[Anna Schumaker]

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 <bjschuma@netapp.com>
---
 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

[PATCH v2 3/3] NFSD: Implement SEEK

[Anna Schumaker]

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 <bjschuma@netapp.com>

---
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

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[J. Bruce Fields]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[Anna Schumaker]

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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[J. Bruce Fields]

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.

[PATCH v2 1/3] NFSD: Update error codes

[Anna Schumaker]

Recent NFS v4.2 drafts have removed NFS4ERR_METADATA_NOTSUPP and
reassigned the error code to NFS4ERR_UNION_NOTSUPP.

Signed-off-by: Anna Schumaker <bjschuma@netapp.com>
---
 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

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[Marc Eshel]

linux-nfs-owner@vger.kernel.org wrote on 11/12/2013 11:45:29 AM:

> From: "J. Bruce Fields" <bfields@fieldses.org>
> To: Anna Schumaker <bjschuma@netapp.com>, 
> Cc: linux-nfs@vger.kernel.org
> Date: 11/12/2013 12:07 PM
> Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK
> Sent by: linux-nfs-owner@vger.kernel.org
> 
> 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 majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v2 1/3] NFSD: Update error codes

[Marc Eshel]

where do you see this change?, the last version 20 don't show it.
Thanks, Marc.



From:   Anna Schumaker <schumaker.anna@gmail.com>
To:     Anna Schumaker <bjschuma@netapp.com>, bfields@fieldses.org, 
linux-nfs@vger.kernel.org, 
Date:   11/12/2013 12:50 PM
Subject:        [PATCH v2 1/3] NFSD: Update error codes
Sent by:        linux-nfs-owner@vger.kernel.org



Recent NFS v4.2 drafts have removed NFS4ERR_METADATA_NOTSUPP and
reassigned the error code to NFS4ERR_UNION_NOTSUPP.

Signed-off-by: Anna Schumaker <bjschuma@netapp.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[J. Bruce Fields]

On Tue, Nov 12, 2013 at 02:44:21PM -0800, Marc Eshel wrote:
> linux-nfs-owner@vger.kernel.org wrote on 11/12/2013 11:45:29 AM:
> 
> > From: "J. Bruce Fields" <bfields@fieldses.org>
> > To: Anna Schumaker <bjschuma@netapp.com>, 
> > Cc: linux-nfs@vger.kernel.org
> > Date: 11/12/2013 12:07 PM
> > Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK
> > Sent by: linux-nfs-owner@vger.kernel.org
> > 
> > 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.

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[Marc Eshel]

"J. Bruce Fields" <bfields@fieldses.org> wrote on 11/12/2013 03:02:01 PM:

> From: "J. Bruce Fields" <bfields@fieldses.org>
> To: Marc Eshel/Almaden/IBM@IBMUS, 
> Cc: Anna Schumaker <bjschuma@netapp.com>, linux-nfs@vger.kernel.org,
> linux-nfs-owner@vger.kernel.org
> 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:
> > linux-nfs-owner@vger.kernel.org wrote on 11/12/2013 11:45:29 AM:
> > 
> > > From: "J. Bruce Fields" <bfields@fieldses.org>
> > > To: Anna Schumaker <bjschuma@netapp.com>, 
> > > Cc: linux-nfs@vger.kernel.org
> > > Date: 11/12/2013 12:07 PM
> > > Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK
> > > Sent by: linux-nfs-owner@vger.kernel.org
> > > 
> > > 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.
> 

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[J. Bruce Fields]

On Tue, Nov 12, 2013 at 04:32:51PM -0800, Marc Eshel wrote:
> "J. Bruce Fields" <bfields@fieldses.org> wrote on 11/12/2013 03:02:01 PM:
> 
> > From: "J. Bruce Fields" <bfields@fieldses.org>
> > To: Marc Eshel/Almaden/IBM@IBMUS, 
> > Cc: Anna Schumaker <bjschuma@netapp.com>, linux-nfs@vger.kernel.org,
> > linux-nfs-owner@vger.kernel.org
> > 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:
> > > linux-nfs-owner@vger.kernel.org wrote on 11/12/2013 11:45:29 AM:
> > > 
> > > > From: "J. Bruce Fields" <bfields@fieldses.org>
> > > > To: Anna Schumaker <bjschuma@netapp.com>, 
> > > > Cc: linux-nfs@vger.kernel.org
> > > > Date: 11/12/2013 12:07 PM
> > > > Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK
> > > > Sent by: linux-nfs-owner@vger.kernel.org
> > > > 
> > > > 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.

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[Anna Schumaker]

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.
> 

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[Anna Schumaker]

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.
>>
> 

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[Christoph Hellwig]

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.

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[J. Bruce Fields]

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.

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[Christoph Hellwig]

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.

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[Joshuah Hurst]

On Wed, Nov 13, 2013 at 5:49 PM, J. Bruce Fields <bfields@fieldses.org> 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

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[Anna Schumaker]

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.
> 

Re: [PATCH v2 0/3] NFSD: Implement SEEK

[J. Bruce Fields]

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.