Subject: [nfsv4] Fw: New Version Notification for draft-naik-nfsv4-xattrs-02.txt

From: "Manoj Naik" <[email-masked]>
Date: Sun, 5 Jul 2015 19:58:35 -0700

I have just submitted a new revision of the xattr draft. Changes include:
- Add new operations to list/remove; simplify get/set
- Remove restrictions on total size, max size
- More use cases
- Incorporate other comments from mailing list discussion

Manoj.

----- Forwarded by Manoj Naik <[email-masked]> on 07/05/2015 07:51 PM 
-----

From:   [email-masked]
To:     [email-masked], [email-masked]
Date:   07/05/2015 07:46 PM
Subject:        New Version Notification for 
draft-naik-nfsv4-xattrs-02.txt

A new version of I-D, draft-naik-nfsv4-xattrs-02.txt
has been successfully submitted by Manoj Naik and posted to the
IETF repository.

Name:                            draft-naik-nfsv4-xattrs
Revision:                02
Title:                           Support for File System Extended 
Attributes in NFSv4
Document date:           2015-07-06
Group:                           Individual Submission
Pages:                           18
URL:            
https://www.ietf.org/internet-drafts/draft-naik-nfsv4-xattrs-02.txt
Status:         https://datatracker.ietf.org/doc/draft-naik-nfsv4-xattrs/
Htmlized:       https://tools.ietf.org/html/draft-naik-nfsv4-xattrs-02
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-naik-nfsv4-xattrs-02

Abstract:
   This document proposes extensions to existing NFSv4 operations to
   allow file extended attributes (here forth also referred to as
   xattrs) to be manipulated in the protocol. An xattr is a file system
   feature that allows opaque metadata, not interpreted by the file
   system, to be associated with files and directories and are supported
   by many modern file systems. New file attributes are proposed to
   allow clients to query the server for xattr support, and new
   operations to get and set xattrs on file system objects.

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.

The IETF Secretariat

---

From: Christoph Hellwig <[email-masked]>
Date: Mon, 6 Jul 2015 11:14:36 +0200

> - Add new operations to list/remove; simplify get/set

Thanks, from a quick glance the operations look sensible now.

> - Remove restrictions on total size, max size

So how do we handle the cases where the client tries to set an xattr
size, total size or key lenghth that exceeds the servers limit?  We should
define specific error codes for these cases at least.  I also thing
attrs might still be useful, even if some syscall interface currently
can't support those.

---

From: "Manoj Naik" <[email-masked]>
Date: Mon, 6 Jul 2015 17:29:06 +0530

> size, total size or key lenghth that exceeds the servers limit?  We 
should

Here's the text for this from section 6.2.4.3:

   If the xattr key and/or value contained in the client request exceeds
   the channel's negotiated maximum request size, then the server MUST
   return NFS4ERR_REQ_TOO_BIG in sr_status. If the server file system
   imposes additional limits on the size of key name or value, it MAY
   return NFS4ERR_ENOSPC.

> attrs might still be useful, even if some syscall interface currently

This isn't clear - are you asking about get/set of multiple xattrs in a 
single request?

Manoj.

---

From: Benny Halevy <[email-masked]>
Date: Mon, 6 Jul 2015 16:24:16 +0300

>> attrs might still be useful, even if some syscall interface currently

It is more appropriate to return ENOSPC when the backing storage
of the exported file system is exhausted rather than (ab)using it for this case.
How about using NFS4ERR_NAMETOOLONG or define a similar error code?

Benny

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: "Manoj Naik" <[email-masked]>
Date: Mon, 6 Jul 2015 23:08:54 +0530

Benny Halevy <[email-masked]> wrote on 07/06/2015 06:54:16 PM:

> From: Benny Halevy <[email-masked]>
> To: Manoj Naik/Almaden/IBM@IBMUS
> Cc: Christoph Hellwig <[email-masked]>, "nfsv4 list ([email-masked])" 
> <[email-masked]>
> Date: 07/06/2015 06:54 PM
> Subject: Re: [nfsv4] Fw: New Version Notification fordraft-naik-
> nfsv4-xattrs-02.txt
> 

Agreed. BSD lists ENAMETOOLONG if name exceeds max and E2BIG if the value 
is too large. The closest match for the latter is probably NFS4ERR_EFBIG.

Manoj.

---

From: Christoph Hellwig <[email-masked]>
Date: Tue, 7 Jul 2015 10:30:54 +0200

> This isn't clear - are you asking about get/set of multiple xattrs in a 

Just for optional attributs that expose the implementation limits, similar
to those present in the earlier draft.

---

From: Benny Halevy <[email-masked]>
Date: Tue, 7 Jul 2015 12:31:47 +0300

On Mon, Jul 6, 2015 at 8:38 PM, Manoj Naik <[email-masked]> wrote:
> Agreed. BSD lists ENAMETOOLONG if name exceeds max and E2BIG if the value is
> too large. The closest match for the latter is probably NFS4ERR_EFBIG.

You mean NFS4ERR_FBIG?

I think its inappropriate for this case as the error name and
definition refer to
the file operand, in contrast to E2BIG that is more general (but
refers to argument list
too long but that's a different issue)

  15.1.4.4.  NFS4ERR_FBIG (Error Code 27)

     The file is too large.  The operation would have caused the file to
     grow beyond the server's limit.

NFS4ERR_NAMETOOLONG is currently defined as:

  15.1.7.3.  NFS4ERR_NAMETOOLONG (Error Code 63)

     Returned when the filename in an operation exceeds the server's
     implementation limit.

That could be sanely amended to cover the key length in my opinion.
As for the value, it can denote either key or value or a new error code
could be defined.

Benny