Subject: Re: [nfsv4] NFS4ERR_MLINK needs to among RENAME's valid errors

From: "Mike Eisler" <[email-masked]>
Date: Sat, 20 Jun 2009 11:39:33 -0700

On Wed, May 27, 2009 10:07 am, Trond Myklebust wrote:
> On Wed, 2009-05-27 at 11:33 -0400, Peter Staubach wrote:
>> Noveck, Dave wrote:
>> > I'm guessing most servers today return NFS4ERR_IO in this case.
>> >
>> > We have NFS4ERR_FBIG.  I suppose it makes sense to have NFS4ERR_DBIG.

Not in NFSv4.1, though.

>> I think that it makes sense if there are clients which
>> differentiate between the two errors.  Do we know of any?
>> Off hand, I can't think of any.
>
> There is no way that the client can fix this kind of error by itself. It
> needs application guidance, so the question is rather: is there any way
> we can pass this error up the stack?
>
> In POSIX systems the answer would appear to be "no". The closest errors
> I can think of are ENOSPC, EMLINK, EFBIG, and EDQUOT, and all of those
> would be ambiguous in this context. POSIX systems therefore don't seem

So which error do we want? Right now NFS4ERR_NOSPC is common to
OPEN, RENAME, LINK, CREATE (and _MLINK will be added to LINK, but that
is for a different situation). I can live with no change to status quo.

> to justify having a separate NFS4ERR_DBIG.
>
> Does anybody know if Windows could make use of it?
>
> Trond
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Trond Myklebust <[email-masked]>
Date: Sat, 20 Jun 2009 17:35:05 -0400

> > Does anybody know if Windows could make use of it?

Since nobody has volunteered a client that can make use of NFS4ERR_DBIG,
I suggest just sticking with NFS4ERR_IO.

Cheers
  Trond

---

From: Robert Gordon <[email-masked]>
Date: Sat, 20 Jun 2009 17:23:24 -0500

> I suggest just sticking with NFS4ERR_IO.

Indeed.

Robert.