Subject: [nfsv4] 3530bis: Add a new error code for RENAME

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 8 Feb 2012 00:18:57 +0000

We'd like to add NFS4ERR_FBIG as an expected error code for RENAME.

At first blush, this appears to not make sense, I.e., the file size is not changing.

Here is our use case:

EFBIG could be returned if the target directory is about to exceed its
maximum capacity.  Got any really, really big directories on there?

Anyone have any objections to adding this error value?

---

From: Tom Talpey <[email-masked]>
Date: Wed, 22 Feb 2012 20:56:28 +0000

>Anyone have any objections to adding this error value?

What do you expect clients to do with this new error? I don't believe a Posix client can map it to anything useful from a rename(2) call, and I certainly don't see any recovery. Can you elaborate on the justification?

Also, who is "we"?

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 23 Feb 2012 17:18:12 +0000

On 2/22/12 12:56 PM, "Tom Talpey" <[email-masked]> wrote:

>What do you expect clients to do with this new error? I don't believe a
>Posix client can map it to anything useful from a rename(2) call, and I
>certainly don't see any recovery. Can you elaborate on the justification?

Are we restricted to Posix clients?

Is there no way to propose and drive a Posix change?

>Also, who is "we"?

My employer is NetApp and I represent them on this issue.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 23 Feb 2012 17:33:42 +0000

I think the argument for adding a new error return, such as this, is the
server is able to better reflect what occurred that resulted in the error.
Whether the client's operating environment has a direct translation of that
error to its application (even if it has an application to which to return
the error) is a separate issue.

We should evaluate the error return based on the usefulness to the client.
IMO having the error for the stated instance seems reasonable.

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Haynes, Tom
Sent: Thursday, February 23, 2012 9:18 AM
To: Tom Talpey
Cc: nfsv4
Subject: Re: [nfsv4] 3530bis: Add a new error code for RENAME

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

---

From: Peter Staubach <[email-masked]>
Date: Thu, 23 Feb 2012 12:53:26 -0500

I agree with Spencer's assessment.  Although clients may or may not strive to be Posix compliant by mapping the virtual file system models defined by the NFS protocols, the server behavior is more driven by local semantics and the virtual file system models defined by the NFS protocols.

In this case, it would seem that either EFBIG was an oversight because no one could imagine a directory that big or there was other error defined to cover the situation.  Does anyone remember anything about the largefile discussions way back when?

	Thanx...

		ps

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Thursday, February 23, 2012 12:34 PM
To: Haynes, Tom; Tom Talpey
Cc: nfsv4
Subject: Re: [nfsv4] 3530bis: Add a new error code for RENAME

I think the argument for adding a new error return, such as this, is the server is able to better reflect what occurred that resulted in the error.
Whether the client's operating environment has a direct translation of that error to its application (even if it has an application to which to return the error) is a separate issue.

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 23 Feb 2012 18:30:38 +0000

Large files?  Haven't we always had those? :-)

-----Original Message-----
From: Peter Staubach [mailto:[email-masked]] 
Sent: Thursday, February 23, 2012 9:53 AM
To: Spencer Shepler; Haynes, Tom; Tom Talpey
Cc: nfsv4
Subject: RE: 3530bis: Add a new error code for RENAME

	Thanx...

		ps

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Thursday, February 23, 2012 12:34 PM
To: Haynes, Tom; Tom Talpey
Cc: nfsv4
Subject: Re: [nfsv4] 3530bis: Add a new error code for RENAME

Spencer

---

From: Tigran Mkrtchyan <[email-masked]>
Date: Fri, 24 Feb 2012 06:36:21 +0100

Well I have a use case for it.

we keep all inodes as files in a directory. Files get removed if they
are migrated to
tape and space for new inodes are needed. We cold handle cases when filesystem
would tell us that it's too much. Probably there are some other
migration file systems
around which will benefit as well. Of course this requires that such
error code propagated
up to the user lever (read posix).

Nevertheless such  error code may require yet another attribute like
*maxdirsize* to
let clients behave nicely in the first place.

Tigran.

---

From: Peter Staubach <[email-masked]>
Date: Fri, 24 Feb 2012 08:58:57 -0500

Hmm.

I am not sure that I see the point of a "maxdirsize" attribute.  How would a client predict how some metadata operation would affect the size of the directory?  That seems to be attempting to expose a little more about the file system on the server than is appropriate to do.

As always, we should just allow the server to do what it does and return the errors that it needs to return and then let the client deal with the results and errors as it deems appropriate.

	Thanx...

		ps

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tigran Mkrtchyan
Sent: Friday, February 24, 2012 12:36 AM
To: Spencer Shepler
Cc: Peter Staubach; Haynes, Tom; Tom Talpey; nfsv4
Subject: Re: [nfsv4] 3530bis: Add a new error code for RENAME

we keep all inodes as files in a directory. Files get removed if they are migrated to tape and space for new inodes are needed. We cold handle cases when filesystem would tell us that it's too much. Probably there are some other migration file systems around which will benefit as well. Of course this requires that such error code propagated up to the user lever (read posix).

Tigran.

On Thu, Feb 23, 2012 at 7:30 PM, Spencer Shepler <[email-masked]> wrote:
>>>EFBIG could be returned if the target directory is about to exceed 
>>>its maximum capacity.  Got any really, really big directories on there?
>>>
>>What do you expect clients to do with this new error? I don't believe 
>>a Posix client can map it to anything useful from a rename(2) call, 
>>and I certainly don't see any recovery. Can you elaborate on the justification?
>
>

---

From: Trond Myklebust <[email-masked]>
Date: Sat, 25 Feb 2012 12:56:17 -0500

> As always, we should just allow the server to do what it does and return the errors that it needs to return and then let the client deal with the results and errors as it deems appropriate.

ACK... Having the client try to predict what is happening on a
multi-client system is an exercise in futility.

As for the RENAME case, can someone remind me why NFS4ERR_NOSPC isn't
appropriate here? That's certainly the error that I'd expect in a POSIX
environment.

Cheers
  Trond

---

From: Benny Halevy <[email-masked]>
Date: Tue, 28 Feb 2012 11:44:03 +0200

> appropriate here? That's certainly the error that I'd expect in a POSIX

For example, if the file server has a limit on the maximum file size, say
of 2 GB, and say you have a gigantic directory and rename would hit the file
size limit, but there is is still plenty of free space on the file system
NFS4ERR_FBIG would be the right error to return and not NFS4ERR_NOSPC.

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.

15.1.4.9.  NFS4ERR_NOSPC (Error Code 28)

   Indicates there is no space left on the device.  The operation would
   have caused the server's file system to exceed its limit.

Benny

---

From: "Myklebust, Trond" <[email-masked]>
Date: Tue, 28 Feb 2012 13:43:18 +0000

>    grow beyond the server's limit.

Which translates to EFBIG in POSIX. (An attempt was made to write a file
that exceeds the file size limit of the process.)

>    have caused the server's file system to exceed its limit.

In POSIX, the rename() command does allow an ENOSPC, and the
interpretation is: "The directory that would contain new cannot be
extended.". It doesn't allow for EFBIG:
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html)

IOW: I'm strongly against NFS4ERR_FBIG here. All POSIX systems would
have to make a "special" translation just for rename() of NFS4ERR_FBIG
into ENOSPC.

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Benny Halevy <[email-masked]>
Date: Wed, 29 Feb 2012 16:50:00 +0200

> have to make a "special" translation just for rename() of NFS4ERR_FBIG

Forcing the server to return an error that hides information makes little sense to me.
Returning NFS4ERR_FBIG in this case can be specified as SHOULD in the IMPLEMENTATION
section, while documenting the conflict with Posix semantics.

Benny

---

From: "Myklebust, Trond" <[email-masked]>
Date: Wed, 29 Feb 2012 15:01:50 +0000

> section, while documenting the conflict with Posix semantics.

No. We can't document an error code as a SHOULD. Either we choose one or
we choose the other.

My preference is to follow POSIX.

NetApp

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 29 Feb 2012 17:32:18 +0000

Trond,

Is your specific proposal then to expand the NFSv4 protocol's description of
NFS4ERR_NOSPC to include a case where, for RENAME, it means the directory could not be extended and this may be a result of directory limit reached or underlying file system not having space?

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Myklebust, Trond
Sent: Wednesday, February 29, 2012 7:02 AM
To: Benny Halevy
Cc: Haynes, Tom; nfsv4
Subject: Re: [nfsv4] 3530bis: Add a new error code for RENAME

On Wed, 2012-02-29 at 16:50 +0200, Benny Halevy wrote:
> >>> As for the RENAME case, can someone remind me why NFS4ERR_NOSPC 
> >>> isn't appropriate here? That's certainly the error that I'd expect 
> >>> in a POSIX environment.
> >>
> >> For example, if the file server has a limit on the maximum file 
> >> size, say of 2 GB, and say you have a gigantic directory and rename 
> >> would hit the file size limit, but there is is still plenty of free 
> >> space on the file system NFS4ERR_FBIG would be the right error to return and not NFS4ERR_NOSPC.
> >>
> > Which translates to EFBIG in POSIX. (An attempt was made to write a 
> > file that exceeds the file size limit of the process.)
> > 
> > have to make a "special" translation just for rename() of 
> > NFS4ERR_FBIG into ENOSPC.
> 
> 
> Returning NFS4ERR_FBIG in this case can be specified as SHOULD in the 
> IMPLEMENTATION section, while documenting the conflict with Posix semantics.

No. We can't document an error code as a SHOULD. Either we choose one or we choose the other.

NetApp

---

From: "Myklebust, Trond" <[email-masked]>
Date: Wed, 29 Feb 2012 17:42:33 +0000

> NFS4ERR_NOSPC to include a case where, for RENAME, it means the directory could not be extended and this may be a result of directory limit reached or underlying file system not having space?

Yes. Please see the link below to the POSIX rename() definition, and how
the ENOSPC return value is defined to mean 'the directory cannot be
extended'.

Cheers
  Trond

NetApp

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 29 Feb 2012 17:52:02 +0000

Thanks, I did read it.  My email was an attempt to be very clear about the proposal.

Tom, if you are okay with this approach (as are others) then please propose
text for the error code change.

Spencer

> From: Myklebust, Trond [mailto:[email-masked]]
> Sent: Wednesday, February 29, 2012 9:43 AM
> To: Spencer Shepler
> Cc: Benny Halevy; Haynes, Tom; nfsv4
> Subject: RE: [nfsv4] 3530bis: Add a new error code for RENAME
> 
> > Is your specific proposal then to expand the NFSv4 protocol's
> > description of NFS4ERR_NOSPC to include a case where, for RENAME, it
> means the directory could not be extended and this may be a result of
> directory limit reached or underlying file system not having space?
> >
> > Spencer
> 
> > > >>>> I am not sure that I see the point of a "maxdirsize" attribute.
> How would a client predict how some metadata operation would affect the
> size of the directory?  That seems to be attempting to expose a little
> more about the file system on the server than is appropriate to do.
> > > >>>>
> > > >>>> As always, we should just allow the server to do what it does and
> return the errors that it needs to return and then let the client deal
> with the results and errors as it deems appropriate.
> > > >>>>
> > > >>>> 	Thanx...
> > > >>>>
> > > >>>> 		ps
> > > >>>
> > > >>> isn't appropriate here? That's certainly the error that I'd
> > > >>> expect in a POSIX environment.
> > > >>
> > > >> size, say of 2 GB, and say you have a gigantic directory and
> > > >> rename would hit the file size limit, but there is is still
> > > >> plenty of free space on the file system NFS4ERR_FBIG would be the
> right error to return and not NFS4ERR_NOSPC.
> > > >>
> > > > Which translates to EFBIG in POSIX. (An attempt was made to write
> > > > a file that exceeds the file size limit of the process.)
> > > >
> > > > (http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.
> > > > ht
> > > > ml)
> > > >
> > > > IOW: I'm strongly against NFS4ERR_FBIG here. All POSIX systems
> > > > would have to make a "special" translation just for rename() of
> > > Returning NFS4ERR_FBIG in this case can be specified as SHOULD in
> > > the IMPLEMENTATION section, while documenting the conflict with Posix
> semantics.
> >