David Noveck | 18 Apr 15:20 2015
Picon

Fwd: RFC: CLONE operation


---------- Forwarded message ----------
From: David Noveck <davenoveck <at> gmail.com>
Date: Sat, Apr 18, 2015 at 7:47 AM
Subject: Re: [nfsv4] RFC: CLONE operation
To: Bruce Fields <bfields <at> fieldses.org>


> Or maybe something more
> generic-sounding (NFS4ERR_NOTSUPP_ON_FS?) might turn out to be useful
> for other ops some day.

Sounds like a god idea.

> suppose I'd be OK with that, but if we're willing to drop support for
> partial CLONEs entirely, why not just drop support for this one subcase
> which even fewer people care about?

It's hard to be sure about the relative unimportance of these two cases.   The big
worry is that it could change.  As device technology changes, some of the weird configurations that Benny is concerned about might come to seem less weird.

I think there is a way to limit the cases affected to the intersection of these two cases, each now unimportant/rare in itself.  how about adding the  following after the third or fourth paragraph of 15.13.3?

Data areas to be cloned must be aligned according to the clone_blocksize attribute of the source and destination files which generally need to be the same   Errors in alignment result in NFS4ERR_INVAL.  In cases in 
which the clone_blocksize is different for the two files, NFS4ERR_XDEV
will be returned.  An exception is the case in which the source and destination offsets are both zero and the length of the area to be cloned matches the length of the source file.  In this case, the clone_blocksize is irrelevant to the success of the operation and NFS4ERR_XDEV need not be returned simply because the clone_blocksize of the two files are different. 



On Fri, Apr 17, 2015 at 6:01 PM, Bruce Fields <bfields <at> fieldses.org> wrote:
> > Might be a little harsh to make every application always query
> > blocksize on both files just in case some server's really exotic.
>
On Thu, Apr 16, 2015 at 09:45:42PM -0400, David Noveck wrote:
> I don't see that anyone is talking about making the application (or
> the client) do anything like this.  Any requirements would be on the
> server in executing the operation.  the client does not have to
> determine in advance that the operation will succeed.

OK, nobody *has* to, but presumably somebody might *want* to, or we
wouldn't have bothered to provide the clone_blocksize attribute.

> >        A server that supports CLONE but not between the two files
> >        provided will return NFS4ERR_XDEV.
>
> You need to adjust this to deal with a bunch of  issues here
>
>    - I think we have to treat CLONE Support as something that may be
>    different on different fs's.  As written, this says that if you do
>    a clone and source and destination are on an fs that does not
>    support cloning, you return NFS4ERR_XDEV.  i guess that's better
>    than NFSERR$_NOTSUPP but I don't think NS4ERR_XDEV is right either.

Yeah, I was abusing XDEV to cover the unsupported case too--probably a
new NFS4ERR_CLONE_NOTSUPP would be clearer.  Or maybe something more
generic-sounding (NFS4ERR_NOTSUPP_ON_FS?) might turn out to be useful
for other ops some day.

>    - There may be files that cannot be either source or destination of
>    clone (because of something about those files.  In other words the issue
>    might not be the relationship the two files but one of the file itself
>    - Your text assumes that you cn do a clone wit h A a source and B as
>    destination, the reverse id the case.  It mght not always be so.
>
>
>  >       If a server supports CLONE across filesystems, or between files
>  >       on a filesystem for which the "homogeneous" attribute is false,
>  >       then the server SHOULD arrange for the clone_blksize attribute
>  >       to be the same on source and destination.
>
> The server can't arrange for this until he knows the source and
> destination.  For example, in the homogeneous-false case, this is asking
> the server to present the same clone_blocksize for each file in the fs

Sure.  Or if it can't figure out that common clone_blocksize, it could
just turn off the cross-blocksize CLONE.  This shouldn't keep us up at
night.

> Note that the complexity here would go away if we made CLONE copy the whole
> file, which is what most people want to do anyway.  This would make source
> and destination offsets zero, which makes most of the clone_blocksize issue
> go away.

I suppose I'd be OK with that, but if we're willing to drop support for
partial CLONEs entirely, why not just drop support for this one subcase
which even fewer people care about?

--b.

>
> On Thu, Apr 16, 2015 at 3:45 PM, Bruce Fields <bfields <at> fieldses.org> wrote:
>
> > On Thu, Apr 16, 2015 at 06:25:57AM -0400, David Noveck wrote:
> > > The problem that this leaves you is that the description of clone that we
> > > have makes no provision for clone when clone-blocksize of the two fules
> > are
> > > different.  It just says "clone block size", assuming that there is only
> > > one.  It could by modified to say that the larger/GCM should be used and
> > it
> > > could say that XDEV should be returned if the two are different but the
> > > issue does need to be addressed.
> >
> >
> > I don't know, is that case likely?  Might be a little harsh to make
> > every application always query blocksize on both files just in case some
> > server's really exotic.
> >
> > Uh, I guess NFS4ERR_INVAL is the error for the case the arguments are
> > unaligned?
> >
> > Then maybe:
> >
> >         A server that supports CLONE may not support it on all exported
> >         filesystems.  It MUST support the clone_blksize attribute on any
> >         filesystem for which CLONE is supported, and SHOULD NOT support
> >         it on a filesystem for which CLONE is not supported.  Clients
> >         can use presence or absence of this attribute to determine CLONE
> >         support.
> >
> >         A server that supports CLONE but not between the two files
> >         provided will return NFS4ERR_XDEV.
> >
> >         If a server supports CLONE across filesystems, or between files
> >         on a filesystem for which the "homogeneous" attribute is false,
> >         then the server SHOULD arrange for the clone_blksize attribute
> >         to be the same on source and destination.
> >
> > ??
> >
> > --b.
> >
> > >
> > > Are there any volunteers to propose a revision to 15.3 to address this?
> > >
> > > On Thu, Apr 16, 2015 at 12:16 AM, Benny Halevy <bhalevy <at> gmail.com>
> > wrote:
> > >
> > > > On 2015-04-15 20:11, J. Bruce Fields wrote:
> > > > > Benny, could you please fix your mailer?  It's really hard for some
> > of
> > > > > us to read your mail:
> > > >
> > > > Sigh, my mailer sends html formatted messages be default, my apologies.
> > > > This is fixed now, should be ok (as long as I remember to reply
> > > > from the right mailer :-/).
> > > >
> > > > >
> > > > > On Wed, Apr 15, 2015 at 09:23:14AM +0300, Benny Halevy wrote:
> > > > >>     <blockquote cite="mid:20150414212352.GF3005 <at> fieldses.org"
> > > > >>       type="cite">
> > > > >>       <pre wrap="">I don't think clone_blksize is currently
> > documented
> > > > to be a
> > > > >> per-filesystem attribute, and I think it should be.</pre>
> > > > >>     </blockquote>
> > > > >>     <br>
> > > > >>     Some servers may implement hybrid filesystems where different
> > files
> > > > >>     are<br>
> > > > >>     stored on different storage media.  Having just one
> > per-filesystem
> > > > >>     clone_blksize<br>
> > > > >>     attribute might force the server to expose the largest block
> > size it
> > > > >>     supports<br>
> > > > >>     across the filesystem so it might make sense to define the
> > > > >>     per-filesystem<br>
> > > > >>     attribute as MUST implement when CLONE is supported for the
> > > > >>     filesystem<br>
> > > > >>     and define an optional per-file clone_file_blksize attribute
> > that
> > > > >>     may override<br>
> > > > >>     the default one for the filesystem.<br>
> > > > >
> > > > > Then we'd have to do that for every other per-filesystem attribute
> > that
> > > > > might actually vary between files.  That's not practical.  Instead I
> > > > > think you just want to set the "homogeneous" attribute to false:
> > > > >
> > > > >       http://tools.ietf.org/html/rfc5661#section-5.8.2.16
> > > >
> > > > Yup, that would work.
> > > >
> > > > >
> > > > > (I don't think the current linux client actually uses that, though.
> > > > > Seems like it would be a pain to deal with.  In practice I think most
> > > > > servers will want to be homogeneous.)
> > > >
> > > > The pain is to revalidate per-filesystem attrs the client cares about,
> > > > per-file.  It'd be nice to have a mask of which perf-fs attrs are non-
> > > > homogeneous rather than (or in addition to) a bool value...
> > > >
> > > > Benny
> > > >
> > > > >
> > > > > --b.
> > > > >
> > > >
> > > > _______________________________________________
> > > > nfsv4 mailing list
> > > > nfsv4 <at> ietf.org
> > > > https://www.ietf.org/mailman/listinfo/nfsv4
> > > >
> >
> > > _______________________________________________
> > > nfsv4 mailing list
> > > nfsv4 <at> ietf.org
> > > https://www.ietf.org/mailman/listinfo/nfsv4
> >
> >


_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
RFC Errata System | 17 Apr 22:10 2015

[Errata Verified] RFC7530 (4329)

The following errata report has been verified for RFC7530,
"Network File System (NFS) Version 4 Protocol". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7530&eid=4329

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Marcel Telka <marcel <at> telka.sk>
Date Reported: 2015-04-07
Verified by: Martin Stiemerling (IESG)

Section: 21.1.

Original Text
-------------
   [openg_symlink]
              The Open Group, "Section 3.372 of Chapter 3 of Base
              Definitions of The Open Group Base Specifications
              Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version),
              ISBN 1937218287, April 2013, <http://www.opengroup.org/>.

Corrected Text
--------------
   [openg_symlink]
              The Open Group, "Section 3.375 of Chapter 3 of Base
              Definitions of The Open Group Base Specifications
              Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version),
              ISBN 1937218287, April 2013, <http://www.opengroup.org/>.

Notes
-----

--------------------------------------
RFC7530 (draft-ietf-nfsv4-rfc3530bis-35)
--------------------------------------
Title               : Network File System (NFS) Version 4 Protocol
Publication Date    : March 2015
Author(s)           : T. Haynes, Ed., D. Noveck, Ed.
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

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

David Noveck | 15 Apr 11:37 2015
Picon

review of new section in draft-ietf-nfsv4-minorversion2-35

Here's my contribution to the current minoverversion2 last call (for the -35), with over a day to spare.

It looks like there will be a -36 at least, and presumably, yet another last call.  In any case, I'd like to get these issues in the current section 15.3 addressed as soon as possible

Section 15.3:

since this clones a byte/block range, perhaps the title should reflect this.

Section 15.3.3:

In this section, it isn't clear why "MUST fail" is used in some places and "will fail" in others.

Since we may eventually decide to revise the first paragraph to be more clear about how 
cloning and copying relate, I'll limit myself for now, to a few low-level issues.
  • Suggest that the comma after "e.g." be removed.
  • Suggest replacing "'copy on write" by "copy-on-write"
Within the second paragraph;
  • It's unclear whether named attributes are included as "regular files"
  • Suggest replacing "are not regular files" by "is not a regular file".
I don't see the point of the fourth paragraph.  We don't do this for other operations that use the saved_fh.

There are some issues in the sixth paragraph that should be addressed:
  • The words "read" and "written" are used in a way that suggest the data is copied, while in other cases efforts are made to avoid saying that the data is copied.  You can say the data is cloned (and not copied) or that it's effectively copied by cloning or that it is copied, with the means by which copying occurs being immaterial. The text should pick one story and stick to it.
  • The handling of the case in which cl_size is zero should be clearer.
Here's my attempt to revise this using the "hey, we're cloning, not copying" approach:

The cl_src_offset is the starting offset within the source file from which the data to be cloned will be obtained and the cl_dst_offset is the starting offset of the target region into which the cloned data will be placed. An offset of 0 (zero) indicates the start of the respective file. The number of bytes to be cloned is obtained from cl_count, except that a cl_count of 0 (zero) indicates that the number of bytes to be cloned is the count of bytes between cl_src_offset and the EOF of the source file. Both cl_src_offset and cl_dst_offset must be aligned to the clone block size. The number of bytes to be cloned must be a multiple of the clone block size, except in the case in which cl_src_offset plus the number of bytes to be cloned is equal to the source file size.


To be consistent with the above, the eighth paragraph could be written as follows:

If the target area of the clone operation ends beyond the end of the destination file, the offset at the end of the target area will determine the new size of the destination file.  The contents of any block not part of the target area will be the same as if the file size were extended by a WRITE,


I think you need to add a paragraph like the following after the eight paragraph:

If the area to be cloned is not a multiple of the clone block size and the size of the destination file is past the end of the target area, the area between the end of the target area and the nexrt multiple o the clone block size wlll be zeroed.
 
The ninth paragraph, as written, is not consistent with my understanding of atomicity.  Suggest the following replacement;

The CLONE operation is atomic in that other operations may not see see any intermediate states between the state of the two files before the operation and that after the operation.    READs of the destination file will never see some blocks of the target area cloned without all of them being cloned.  WRITEs of the source area will either have no effect on the data of the target file or be fully reflected in the target area of the destination file.
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Spencer Shepler | 13 Apr 20:01 2015
Picon

IETF 93 - Prague - NFSv4 meeting

 

I would like to solicit agenda items for the Prague meeting.  WG scheduling requests start on April 20th.

 

Please send me your items for discussion.

 

Meeting is July 19-24.

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Tom Haynes | 10 Apr 20:13 2015

[PATCH] *** Proposed change on stats ***

In looking at the stats, the size of the count was
unbalanced. Also, the restriction of resetting the
stats seems harsh.

Comments?

Tom Haynes (1):
  Allow for accumlation of stats

 dotx.d/type_io_info.x            | 2 +-
 nfsv42_middle_op_layoutstats.xml | 6 ++++--
 2 files changed, 5 insertions(+), 3 deletions(-)

--

-- 
1.8.3.1

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

Barry Leiba | 9 Apr 20:33 2015
Picon

Barry Leiba's No Objection on draft-ietf-nfsv4-lfs-registry-05: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-nfsv4-lfs-registry-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-lfs-registry/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Version -05 addresses my most significant comment, and thanks very much
for that.

Some non-blocking, minor comments here:

Very much a nit, but drafts have this sort of thing all the time, and we
should probably say something more generally (I think I'll post to the
IETF discussion list about the general point):

In the abstract...

   To allow multiple MAC mechanisms and label formats to co-exist in a
   network, this document proposes a registry of label format
   specifications.  This registry would contain label format identifiers
   and would provide for the association of each such identifier with a
   corresponding extensive document document outlining the exact syntax
   and use of the particular label format.

When the draft was written, it was "proposing" a registry, and should
that registry be created it "would contain" and "would provide" things. 
But it's now up for approval for RFC publication, and these
characterizations are inapt; when it's published, the registry will have
been created and will be providing all that.  Drafts should be written --
at least by the time they enter last call -- to have the right tone as
published RFCs.  Here, I suggest these changes:

1. "proposes" -> "creates"
2. "would contain" -> "contains"
3. "would provide" -> "provides"

-- Section 5 --
As best I can tell, this question from IANA wasn't answered in the last
call discussion, and it needs to be:

> Where should this new registry be located? Should it be placed at an
> existing URL? If not, should the title of the new webpage be "NFS
> Security Label Format Selection," or do you expect other registries
> that would require a different title to be placed there? Also, should
> it be filed under a new or an existing category at
http://www.iana.org/protocols?

IANA will sort this out with you in any case, but it would be good for
the document to say where you would like IANA to put the registry.

In Table 1, I think "Available for IANA Assignment" would be better than
"Reserved for IANA Assignment", but it's a really small point.

In Section 5.2, I suggest using the full name for the registry (add the
word "Security").

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

internet-drafts | 9 Apr 19:50 2015
Picon

New Version Notification - draft-ietf-nfsv4-lfs-registry-05.txt


A new version (-05) has been submitted for draft-ietf-nfsv4-lfs-registry:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-lfs-registry-05.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-lfs-registry/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-lfs-registry-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

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

internet-drafts | 9 Apr 19:50 2015
Picon

I-D Action: draft-ietf-nfsv4-lfs-registry-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Registry Specification for Mandatory Access Control (MAC) Security Label Formats
        Authors         : David P. Quigley
                          Jarrett Lu
                          Thomas Haynes
	Filename        : draft-ietf-nfsv4-lfs-registry-05.txt
	Pages           : 9
	Date            : 2015-04-09

Abstract:
   In the past Mandatory Access Control (MAC) systems have used very
   rigid policies which were implemented in particular protocols and
   platforms.  As MAC systems became more widely deployed, additional
   flexibility in mechanism and policy will be required.  While
   traditional trusted systems implemented Multi-Level Security (MLS)
   and integrity models, modern systems have expanded to include
   technologies such as type enforcement.  Due to the wide range of
   policies and mechanisms which need to be accommodated, it is unlikely
   that use of a single security label format and model will be viable.

   To allow multiple MAC mechanisms and label formats to co-exist in a
   network, this document proposes a registry of label format
   specifications.  This registry would contain label format identifiers
   and would provide for the association of each such identifier with a
   corresponding extensive document document outlining the exact syntax
   and use of the particular label format.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-lfs-registry/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-lfs-registry-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-lfs-registry-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

IETF Secretariat | 9 Apr 19:48 2015
Picon

ID Tracker State Update Notice: <draft-ietf-nfsv4-lfs-registry-04.txt>

IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-nfsv4-lfs-registry/

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

J. Bruce Fields | 9 Apr 17:46 2015

[PATCH 1/2] removed unused file

From: "J. Bruce Fields" <bfields <at> redhat.com>

Signed-off-by: J. Bruce Fields <bfields <at> redhat.com>
---
 nfsv42_middle_op_cb_attr_changed.xml | 52 ------------------------------------
 1 file changed, 52 deletions(-)
 delete mode 100644 nfsv42_middle_op_cb_attr_changed.xml

diff --git a/nfsv42_middle_op_cb_attr_changed.xml b/nfsv42_middle_op_cb_attr_changed.xml
deleted file mode 100644
index d3a2e5323395..000000000000
--- a/nfsv42_middle_op_cb_attr_changed.xml
+++ /dev/null
 <at>  <at>  -1,52 +0,0  <at>  <at> 
-<!-- Copyright (C) The IETF Trust (2011) -->
-<!-- Copyright (C) The Internet Society (2011) -->
-
-<section anchor='ss:cb:lc' title="Procedure 16: CB_ATTR_CHANGED - Notify Client that the File's
Attributes Changed">
-  <section toc='exclude' anchor="ss:cbac:args" title="ARGUMENTS">
-    <t>
-      &lt;CODE BEGINS&gt;
-    </t>
-
-    <?rfc include='autogen/cb_attr_changed_args.xml'?>
-
-    <t>
-      &lt;CODE ENDS&gt;
-    </t>
-  </section>
-
-  <section toc='exclude' anchor="ss:cbac:result" title="RESULTS">
-    <t>
-      &lt;CODE BEGINS&gt;
-    </t>
-
-    <?rfc include='autogen/cb_attr_changed_res.xml'?>
-
-    <t>
-      &lt;CODE ENDS&gt;
-    </t>
-  </section>
-
-  <section toc='exclude' anchor="ss:cbac:desc" title="DESCRIPTION">
-    <t>
-      The CB_ATTR_CHANGED callback operation is used by the
-      server to indicate to the client that the file's attributes
-      have been modified on the server. The server does not
-      convey how the attributes have changed, just that they
-      have been modified.  The server can inform the client
-      about both critical and informational attribute changes
-      in the bitmask arguments. The client SHOULD query the
-      server about all attributes set in acca_critical. For
-      all changes reflected in acca_info, the client can decide
-      whether or not it wants to poll the server.
-    </t>
-
-    <t>
-      The CB_ATTR_CHANGED callback operation with the FATTR4_SEC_LABEL
-      set in acca_critical is the method used by the
-      server to indicate that the MAC label for the file
-      referenced by acca_fh has changed. In many ways, the
-      server does not care about the result returned by the
-      client.
-    </t>
-  </section>
-</section>
--

-- 
1.9.3

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

Stephen Farrell | 8 Apr 15:04 2015
Picon
Picon

Stephen Farrell's No Objection on draft-ietf-nfsv4-lfs-registry-04: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-nfsv4-lfs-registry-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-lfs-registry/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think there is a possibly missing security consideration in
section 4 - if two label formats "overlap" so that a value for
one could represent a (different) value for the other and if
the label format specifier is not somehow bound to the
packet/object, then some confusion attacks may be possible.
The mitigation I think is to either (maybe implicitly) bind
the format specifier into the object/label or to ensure that
label values cannot be valid for other label format
specifiers. (Note that attacks here are probably only
interesting in highly specific cases, so it's not a huge deal,
but maybe worth a mention.)

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


Gmane