Subject: [nfsv4] NFS4ERR_BAD_STATEID cannot be returned for LAYOUTCOMMIT

From: Benny Halevy <[email-masked]>
Date: Thu, 03 Oct 2013 18:18:30 +0300

Folks,

Any reason why LAYOUTCOMMIT can't return NFS4ERR_BAD_STATEID
when loca_stateid is not found:
   The loca_stateid is a layout stateid value as returned by previously
   successful layout operations (see Section 12.5.3).

Apparently LAYOUTCOMMIT must return NFS4ERR_BADLAYOUT...
   If the layout identified in the arguments does not exist, the error
   NFS4ERR_BADLAYOUT is returned.  The layout being committed may also
   be rejected if it does not correspond to an existing layout with an
   iomode of LAYOUTIOMODE4_RW.

Returning NFS4ERR_BAD_STATEID makes more sense if the server gets
for example the LAYOUTCOMMIT after a final LAYOUTRETURN or CLOSE
where the layout state is invalidated.

Benny

---

From: "Noveck, David" <[email-masked]>
Date: Fri, 4 Oct 2013 13:36:54 -0400

I don't know of a good reason.

I think this may wind up being an issue that we'll have to address in draft-ietf-nfsv4-rfc5661-migration-update.   If there is filesystem migration for the metadata server, the client has to be able to determine whether the MDFS migration is or isn't accompanied by transparent state migration.  The normal way of finding out that stateids have not been transparently migrated is getting NFS4ERR_BAD_STATEID.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Benny Halevy
Sent: Thursday, October 03, 2013 11:19 AM
To: nfsv4 mailing list
Subject: [nfsv4] NFS4ERR_BAD_STATEID cannot be returned for LAYOUTCOMMIT

Folks,

Any reason why LAYOUTCOMMIT can't return NFS4ERR_BAD_STATEID when loca_stateid is not found:
   The loca_stateid is a layout stateid value as returned by previously
   successful layout operations (see Section 12.5.3).

Returning NFS4ERR_BAD_STATEID makes more sense if the server gets for example the LAYOUTCOMMIT after a final LAYOUTRETURN or CLOSE where the layout state is invalidated.

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

---

From: Benny Halevy <[email-masked]>
Date: Fri, 4 Oct 2013 21:43:51 +0300

Agreed
On Oct 4, 2013 8:37 PM, "Noveck, David" <[email-masked]> wrote:

> I think this may wind up being an issue that we'll have to address in
> draft-ietf-nfsv4-rfc5661-migration-update.   If there is filesystem
> migration for the metadata server, the client has to be able to determine
> whether the MDFS migration is or isn't accompanied by transparent state
> migration.  The normal way of finding out that stateids have not been
> transparently migrated is getting NFS4ERR_BAD_STATEID.
>
> Returning NFS4ERR_BAD_STATEID makes more sense if the server gets for
> example the LAYOUTCOMMIT after a final LAYOUTRETURN or CLOSE where the
> layout state is invalidated.
>
> Benny