[nfsv4] What does NFS4ERR

[nfsv4] What does NFS4ERR_NOTSUPP mean?

Thomas Haynes <thomas@netapp.com> Mon, 25 April 2011 22:23 UTC

Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Thomas Haynes <thomas@netapp.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0417416F75@MX14A.corp.emc.com>
Date: Mon, 25 Apr 2011 15:55:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <9723EA95-A955-4969-B116-48B2AC55A476@netapp.com>
References: <B637DE01-CC65-4393-8F57-3C0422E4E6AA@netapp.com> <41be156de393c5e2948b0222230aa6e6.squirrel@webmail.eisler.com> <3D8ED82E-80F3-4B5B-8C71-088E344F47F2@netapp.com> <4DA48A76.5080305@gmail.com> <D9ECA635-BD66-4369-915F-747AE70B4EEE@netapp.com> <4DAD2D3F.6030107@gmail.com> <16CC3EFE-A0EC-48D1-B46C-47D25EAFDF59@netapp.com> <4DADBB52.3050703@gmail.com> <9987c84e8502b72afacc688c5198c0f8.squirrel@webmail.eisler.com> <0B17B345-A600-4BDD-AB61-30A627D735D6@netapp.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0417416F75@MX14A.corp.emc.com>
To: "<david.black@emc.com>" <david.black@emc.com>
Cc: nfsv4@ietf.org
Subject: [nfsv4] What does NFS4ERR_NOTSUPP mean?
Precedence: list

On Apr 25, 2011, at 3:13 PM, <david.black@emc.com> <david.black@emc.com> wrote:

> Returning to the pNFS question, pattern support almost certainly varies by layout type.

Ahh, the question was different:

If we allow both a pattern and a hole to be represented in the INITIALIZE and READ_PLUS
operations, is it conceivable that someone implements holes, but not patterns?

And that actually raises a far more interesting, and generic question, given the minor
versioning rules of NFSv4.x, is it possible to return NFS4ERR_NOTSUPP for one
variant of an operation, but not another?

Look at rule 3 of the Minor Versioning Rules:

   3.   Minor versions must not modify the structure of an existing
        operation's arguments or results.

        Again, the complexity of handling multiple structure definitions
        for a single operation is too burdensome.  New operations should
        be added instead of modifying existing structures for a minor
        version.

        This rule does not preclude the following adaptations in a minor
        version:

        *  adding bits to flag fields, such as new attributes to
           GETATTR's bitmap4 data type, and providing corresponding
           variants of opaque arrays, such as a notify4 used together
           with such bitmaps

        *  adding bits to existing attributes like ACLs that have flag
           words

        *  extending enumerated types (including NFS4ERR_*) with new
           values

        *  adding cases to a switched union

So if we define FOO thusly in NFSv4.2 and make it optional:

enum foo_enum {
  FOO_READ_NORMAL = 0
};

struct foo_reader {
       offset_t  fr_start;
};

union foo_content switch (foo_enum bar) {
case FOO_READ_NORMAL:
       foo_reader       fc_normal;
default:
        void;
};

struct FOO4args {
        foo_content     fa_content;
};

And if further, we redefine FOO in NFSv4.3 to include a new variant:

const NFS4_TWO_GB            = 0x80000000;

typedef opaque twoGB_byte_array4[NFS4_INT32_MAX];

struct fourGB_buffer4 {
     twoGB_byte_array4[2];
}

struct large_buffer4 {
        fourGB_buffer4 lb_big_buffers<>;
        opaque         lb_small_buffer<>;
}

struct foo_large_reader {
        large_buffer4        rwar_data;
};

enum foo_enum {
  FOO_READ_NORMAL = 0,
  FOO_READ_LARGE = 1
};

struct foo_reader {
       offset_t  fr_start;
};

union foo_content switch (foo_enum bar) {
case FOO_READ_NORMAL:
       foo_reader       fc_normal;
case FOO_READ_LARGE:
       foo_large_reader fc_large;
default:
        void;
};

struct FOO4args {
        foo_content     fa_content;
};

I.e., I've come up with a way to add large file support to new READ and WRITE operations without
having to form yet more operations.

An implementation may decide to ship NFSv4.3 without large file support, but with normal file
support for FOO.

I would argue that if it got:

PUTFH FOO {FOO_READ_LARGE} ...

it could return NFS4ERR_NOTSUPP for FOO, but that only means it is not supported for the given
value of the foo_enum.

I.e., if given

PUTFH FOO {FOO_READ_NORMAL}, then it would never return NFS4ERR_NOTSUPP. (Especially
if we made FOO mandatory in NFSv4.3.)

Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Thomas Haynes
[nfsv4] Patterns: INITIALIZE or WRITE_PLUS Thomas Haynes
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Mike Eisler
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Thomas Haynes
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Dean
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Trond Myklebust
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Thomas Haynes
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Trond Myklebust
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Thomas Haynes
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Trond Myklebust
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Thomas Haynes
[nfsv4] Large reads and writes Thomas Haynes
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Dean
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Thomas Haynes
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Dean
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Mike Eisler
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS Thomas Haynes
Re: [nfsv4] Patterns: INITIALIZE or WRITE_PLUS david.black
[nfsv4] What does NFS4ERR_NOTSUPP mean? Thomas Haynes