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

From: "Mike Eisler" <[email-masked]>
Date: Tue, 26 May 2009 12:18:54 -0700 (PDT)

It is for LINK and CREATE.

Does anyone disagree that NFS4ERR_MLINK needs to be returned by RENAME?

Also, while I am at it, suppose a file system has a maximum size (either
in entries or bytes) for a directory. What error should be returned when
an attempt (via RENAME, LINK, CREATE, OPEN, are there others?) to exceed a
maximum is done?

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 26 May 2009 17:36:23 -0400

I think I do.  I'm also not sure when it would be returned by CREATE.

If you CREATE a file and there is already a file with that name, you get
NFS4ERR_EXIST, no matter what the link count.  On the other hand if it
doesn't, you get a file with link count one.

With RENAME, the link count of the source file is not changed.  Unless
it is allowed to have different maximum link counts based on the
directory you are in, NFS4ERR_MLINK shouldn't be possible.

If the destination name already exists, then that file has its link
count reduced and if reduced to zero, then deleted.

> Also, while I am at it, suppose a file system has a 
> maximum size (either in entries or bytes) for a directory. 
> What error should be returned when an attempt (via RENAME, 
> LINK, CREATE, OPEN, are there others?) to exceed a maximum 
> is done?

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.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Tuesday, May 26, 2009 3:19 PM
To: [email-masked]
Subject: [nfsv4] NFS4ERR_MLINK needs to among RENAME's valid errors

Also, while I am at it, suppose a file system has a maximum size (either
in entries or bytes) for a directory. What error should be returned when
an attempt (via RENAME, LINK, CREATE, OPEN, are there others?) to exceed
a maximum is done?

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 26 May 2009 19:12:39 -0400

OK.  I see the issue.  This is create or rename of a directory where the
filesystem has a hard link for every subdirectory.

This has always struck me as kind of weird since you can't have hard
links to directories.  The numlinks value for a directory doesn't really
have any real purpose (it isn't counted down for the number of links
with the file/directory deleted when the count).  But since directories
has .. which pointed to the parent this was considered a link. 

With v4 , which has LOOKUPP, instead of the ..-entry, the case for this
is weaker.  I don't think that there's any place in the spec that
obliges you the server to bump numlinks for subdirectories although
applications may expect it.  

Anyway, since server MAY (and probably will) bump numlinks in this
situation, I think NFS4ERR_MLINK should be returnable by LINK, CREATE,
RENAME.

-----Original Message-----
From: Noveck, Dave 
Sent: Tuesday, May 26, 2009 5:36 PM
To: Mike Eisler; [email-masked]
Subject: Re: [nfsv4] NFS4ERR_MLINK needs to among RENAME's valid errors

> Also, while I am at it, suppose a file system has a maximum size 
> (either in entries or bytes) for a directory.
> What error should be returned when an attempt (via RENAME, LINK, 
> CREATE, OPEN, are there others?) to exceed a maximum is done?

---

From: Peter Staubach <[email-masked]>
Date: Wed, 27 May 2009 11:33:33 -0400

> directory you are in, NFS4ERR_MLINK shouldn't be possible.

Unless the underlying file system uses link counts during
intermediate processing and fails the rename because it can't
correctly process due to link count restrictions.

I would have to agree that this might not be the most clever
file system that I could imagine, but I wouldn't be surprised
if something like UFS worked this way.

> We have NFS4ERR_FBIG.  I suppose it makes sense to have NFS4ERR_DBIG.

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.

       ps

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 27 May 2009 13:07:07 -0400

> 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
to justify having a separate NFS4ERR_DBIG.

Does anybody know if Windows could make use of it?

Trond