Thomas Haynes | 22 Apr 20:38 2014

0000-Get-rid-of-ADHs-long-live-ADB


Proposal to get rid of the ADH (and WRITE_SAME) and replace
it with an ADB. This will reduce the complexity in READ_PLUS
and SEEK.

This version incorporates feedback from Christoph and pulls
in changes from his patchset yesterday:
some cleanup for the WRITE_PLUS split
and the one today:
WRITE_HOLE and WRITE_SAME description should reference stable_how4

Note that I chose to keep the Section 7 seperate.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Thomas Haynes | 22 Apr 17:50 2014
Picon

Re: Proposal for integrating application data holes into the traditional file model


On Apr 21, 2014, at 11:40 PM, Christoph Hellwig <hch <at> infradead.org> wrote:

> On Mon, Apr 21, 2014 at 01:54:40PM -0700, Tom Haynes wrote:
>> The proposal by Christoph here is to introduce a WRITE_SAME modeled after the T10
>> WRITE_SAME.
>> 
>> I'll counter-propose that we take the basic idea, but leave a full fledged
>> WRITE_SAME for another day.
> 
> This seems to be very similar to the earlier WRITE SAME versions in SBC.
> 
> I've looked over your proposal and like it in general.  One highlevel
> question is if we really should even bother with the ADH high-level
> concept, that is give it it's own section and description.  The
> abstraction only matters for the arguments to WRITE_ADB, but not
> anywhere outside, so I'd consolidate all the information about it there.

Agreed, I was saving that as a second pass item.

> And btw, I'd prefer WRITE_SAME over WRITE_ADH just because people are
> familar with it.

I'll change it back.
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

(Continue reading)

Thomas Haynes | 22 Apr 17:29 2014

Re: [PATCH] Let the client inform the server as to what arms it supports in READ_PLUS


On Apr 21, 2014, at 11:34 PM, Christoph Hellwig <hch <at> infradead.org> wrote:

> Passing this in for every READ_PLUS seems wasteful.  A filesystem-wide
> attribute sounds more suitable to me.
> 

How?

It is the client that is informing the server as to what it will accept. The filesystem
lives on the server.

Options:

1) Encode the fact that the client supports HOLES in EXCHANGE_ID.

Con: Does not expand.

2) Create a new operation: DATA_TYPE_MASK that the client can use to 
register which types it will accept.

If not sent, then the use of READ_PLUS by the client creates a default of
all types?

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

(Continue reading)

Christoph Hellwig | 22 Apr 15:32 2014
Picon

[PATCH] WRITE_HOLE and WRITE_SAME description should reference stable_how4


Signed-off-by: Christoph Hellwig <hch <at> lst.de>

diff --git a/nfsv42_middle_op_write_hole.xml b/nfsv42_middle_op_write_hole.xml
index 5cf4704..eda0191 100644
--- a/nfsv42_middle_op_write_hole.xml
+++ b/nfsv42_middle_op_write_hole.xml
 <at>  <at>  -3,6 +3,7  <at>  <at> 

 <section anchor='op:write_hole' title='Operation 64: WRITE_HOLE'>
   <section toc='exclude' title="ARGUMENT">
+    <?rfc include='autogen/stable_how4.xml'?>
     <?rfc include='autogen/data_info4.xml'?>
     <?rfc include='autogen/write_hole_args.xml'?>
   </section>
diff --git a/nfsv42_middle_op_write_same.xml b/nfsv42_middle_op_write_same.xml
index 01c695f..5c84ef8 100644
--- a/nfsv42_middle_op_write_same.xml
+++ b/nfsv42_middle_op_write_same.xml
 <at>  <at>  -3,6 +3,7  <at>  <at> 

 <section anchor='op:write_same' title='Operation 68: WRITE_SAME'>
   <section toc='exclude' title="ARGUMENT">
+    <?rfc include='autogen/stable_how4.xml'?>
     <?rfc include='autogen/app_data_hole4.xml'?>
     <?rfc include='autogen/write_same_args.xml'?>
   </section>

_______________________________________________
nfsv4 mailing list
(Continue reading)

Thomas Haynes | 22 Apr 08:12 2014

0000-Get-rid-of-ADHs-long-live-ADB


Proposal to get rid of the ADH (and WRITE_SAME) and replace
it with an ADB. This will reduce the complexity in READ_PLUS
and SEEK.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Thomas Haynes | 22 Apr 06:44 2014

[PATCH] Let the client inform the server as to what arms it supports in READ_PLUS

From: Tom Haynes <thomas.haynes <at> primarydata.com>

Signed-off-by: Tom Haynes <thomas.haynes <at> primarydata.com>
---
 Makefile                       |  4 +++-
 dotx.d/Makefile                |  3 ++-
 dotx.d/read_plus_args.x        |  7 ++++---
 dotx.d/spit_types.sh           | 16 ++++++++++++---
 nfsv42_middle_op_read_plus.xml | 45 ++++++++++++++++++++++++++----------------
 5 files changed, 50 insertions(+), 25 deletions(-)

diff --git a/Makefile b/Makefile
index 1c04c33..2374c95 100755
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -1,4 +1,4  <at>  <at> 
-# Copyright (C) The IETF Trust (2011-2013)
+# Copyright (C) The IETF Trust (2011-2014)
 #
 # Manage the .xml for the NFSv4 minorversion 2 document.
 #
 <at>  <at>  -153,6 +153,7  <at>  <at>  SPITGEN =	dotx.d/type_nfstime4.x \
 		dotx.d/const_aclflag4.x \
 		dotx.d/const_access_deny.x \
 		dotx.d/const_sizes.x \
+		dotx.d/const_data_types_supported4.x \
 		dotx.d/type_nfs_cb_opnum4.x \
 		dotx.d/type_nfs_cb_argop4.x \
 		dotx.d/type_CB_COMPOUND4args.x \
 <at>  <at>  -231,6 +232,7  <at>  <at>  SPITGENXML =	autogen/type_nfstime4.xml \
(Continue reading)

Tom Haynes | 22 Apr 02:03 2014

Re: New Version Notification for draft-quigley-nfsv4-lfs-registry-00.txt

Hi, this registry has gone through several iterations as an independent draft: http://datatracker.ietf.org/doc/draft-quigley-label-format-registry/

We’ve pushed it over to the WG and would like to see it go forward.

Any comments?

On Apr 21, 2014, at 5:00 PM, internet-drafts <at> ietf.org wrote:

> 
> A new version of I-D, draft-quigley-nfsv4-lfs-registry-00.txt
> has been successfully submitted by Thomas Haynes and posted to the
> IETF repository.
> 
> Name:		draft-quigley-nfsv4-lfs-registry
> Revision:	00
> Title:		Registry Specification for Mandatory Access Control (MAC) Security Label Formats
> Document date:	2014-04-21
> Group:		Individual Submission
> Pages:		8
> URL:            http://www.ietf.org/internet-drafts/draft-quigley-nfsv4-lfs-registry-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-quigley-nfsv4-lfs-registry/
> Htmlized:       http://tools.ietf.org/html/draft-quigley-nfsv4-lfs-registry-00
> 
> 
> Abstract:
>   In the past Mandatory Access Control (MAC) systems have used very
>   rigid policies which were hardcoded into the particular protocol and
>   platform.  As MAC systems are more widely deployed additional
>   flexibility in mechanism and policy is required.  Where traditional
>   trusted systems implemented Multi-Level Security (MLS) and integrity
(Continue reading)

Tom Haynes | 21 Apr 23:21 2014

Re: [PATCH] Adding consecutive byte indicator to source server list


On Apr 21, 2014, at 8:30 AM, Christoph Hellwig <hch <at> infradead.org> wrote:

> On Sun, Apr 20, 2014 at 11:09:27PM -0700, Thomas Haynes wrote:
>> --compose failed.
>> 
>> This new flag will allow servers to inform clients if a consecutive byte oder copied
>> will be done. In turn this allows clients to restart after interruptions.
>> 
>> Comments?
> 
> This looks useful for me, but one thing this doesn't address is failure
> behavior if the flag is not set.  I think the only sensible failure
> behavior for a non-consecutive copy is that no bytes must appear as
> copied in the filesystem either during a copy or after a failed copy,
> while for a consecutive we could allow it to a) be visible partially
> during the copy, and b) remain in place in the truncated form.
> 

I started to argue that the failure behavior if the flag is not set is what
we currently have in place.

The problem with what I originally proposed is that the client:

1) has no way of influencing the destination to use a contiguous copy or not.

2) determining which copy engine that the destination chose

The client would need to add to the COPY operation that it would
prefer that the destination use the contiguous copy. But there might
(Continue reading)

Christoph Hellwig | 21 Apr 18:00 2014
Picon

some cleanup for the WRITE_PLUS split

Clean up a few bits after the WRITE_PLUS split: only mention WRITE_HOLE
in the sparse file related sections, and only WRITE_SAME in the ADH-related
section, don't pair the two in enumerations of operations and update
the actual command descriptions to reflect reality.  The two descriptions
still refer to the 4.1 WRITE description a lot, which might be another
target to rewrite into a standalone form as there's not much shared with
WRITE now.

diff --git a/nfsv42_middle_introduction.xml b/nfsv42_middle_introduction.xml
index 72ce829..5ee9208 100644
--- a/nfsv42_middle_introduction.xml
+++ b/nfsv42_middle_introduction.xml
 <at>  <at>  -123,8 +123,8  <at>  <at> 
     <section title="Application Data Hole (ADH) Support">
       <t>
         Some applications treat a file as if it were a disk and as such
-        want to initialize (or format) the file image. We extend both
-        READ_PLUS and introduce WRITE_SAME (see <xref target='op:write_same' />)
+        want to initialize (or format) the file image. We extend READ_PLUS
+	and introduce WRITE_SAME (see <xref target='op:write_same' />)
         to understand this metadata as a new form of a hole.
       </t>
     </section>
diff --git a/nfsv42_middle_op_cb_offload.xml b/nfsv42_middle_op_cb_offload.xml
index dcd3d57..843c130 100644
--- a/nfsv42_middle_op_cb_offload.xml
+++ b/nfsv42_middle_op_cb_offload.xml
 <at>  <at>  -30,7 +30,10  <at>  <at> 
           the COPY operation
         </t>
(Continue reading)

Christoph Hellwig | 21 Apr 17:16 2014
Picon

include the right data type for WRITE_SAME argument description

WRITE_SAME needs the defintion of app_data_hole4, but not of data_info4.

diff --git a/nfsv42_middle_op_write_same.xml b/nfsv42_middle_op_write_same.xml
index 30c779c..01c695f 100644
--- a/nfsv42_middle_op_write_same.xml
+++ b/nfsv42_middle_op_write_same.xml
 <at>  <at>  -3,7 +3,7  <at>  <at> 

 <section anchor='op:write_same' title='Operation 68: WRITE_SAME'>
   <section toc='exclude' title="ARGUMENT">
-    <?rfc include='autogen/data_info4.xml'?>
+    <?rfc include='autogen/app_data_hole4.xml'?>
     <?rfc include='autogen/write_same_args.xml'?>
   </section>

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Thomas Haynes | 21 Apr 08:09 2014
Picon

Re: [PATCH] Adding consecutive byte indicator to source server list

--compose failed.

This new flag will allow servers to inform clients if a consecutive byte oder copied
will be done. In turn this allows clients to restart after interruptions.

Comments?

On Apr 20, 2014, at 11:07 PM, Thomas Haynes <thomas.haynes <at> primarydata.com> wrote:

> From: loghyr <loghyr <at> gmail.com>
> 
> ---
> Makefile                         |  6 ++++--
> dotx.d/Makefile                  |  3 ++-
> dotx.d/copy_args.x               |  2 +-
> dotx.d/copy_notify_res.x         |  2 +-
> dotx.d/head.x                    |  2 ++
> dotx.d/spit_types.sh             | 14 +++++++++++++-
> nfsv42_middle_copy.xml           |  8 ++++----
> nfsv42_middle_op_copy.xml        | 22 ++++++++++++++--------
> nfsv42_middle_op_copy_notify.xml | 19 ++++++++++++-------
> 9 files changed, 53 insertions(+), 25 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 1c04c33..9a73acf 100755
> --- a/Makefile
> +++ b/Makefile
>  <at>  <at>  -174,7 +174,8  <at>  <at>  SPITGEN =	dotx.d/type_nfstime4.x \
> 		dotx.d/data4.x \
> 		dotx.d/data_content4.x \
(Continue reading)


Gmane