Re: remote I/O error nfs4err_resource

On Wed, 2010-07-14 at 16:14 -0500, Christopher Weis wrote:
> I just joined the list, so sorry for the lack of an inline response.
>  I appear to be running into the same issue recently discussed here...
> http://marc.info/?l=linux-nfsv4&m=127732700529997&w=2
> The thread was left with the following note: "The only solution to that problem, as far as I know, is to hunt
down those clients which are keeping huge numbers of open files and/or locks, and possibly move them to a
different server."
> In my case, there is only one client, and I'm dealing with a relatively low file count.  Read/write
delegations are disabled within ONTAP, and something as simple as a "cp -r" or a "tar" of the local /usr
filesystem to the NetApp volume using NFSv4 triggers the remote I/O error.  NFSv3 works fine.  Perhaps
there is something else going on inside of ONTAP
> 
> So, my questions are:
> 1) Is this believed to be an ONTAP issue or a Linux issue (or both)?
> 2) Is Trond's recent patch set (http://thread.gmane.org/gmane.linux.nfs/33353) expected to fix the issue?
> 3) Are there known kernel bugzilla or NetApp BURTs to track the issue(s)?

OnTAP has a fixed size table of stateids: that is a known limitation,
but it is also a deliberate choice in order to ensure that the server
resources can be managed in a predictable manner.
OnTAP also has a bug which can affect you when you turn on delegations:
if the server runs out of free stateid table slots, then the natural
thing would be for it to start asking clients to return delegations.
This is not yet implemented in OnTAP and so Burt 388695 is tracking this
issue.

Current versions of Linux have an issue when you use file locking: they
can end up using a lot of stateids if you have one or several
applications does a lot of lock/unlock cycles but where the file stateid
never gets CLOSEd (which can happen if at least one application has the
file open at any point in time). That is a bug that the above patch set
aims to fix by adding client side support for the RELEASE_LOCKOWNER
operation.

Older versions of Linux also had a problem with delegation management:
instead of returning delegations for files that had seen no recent
activity, they would continue to hoard them until either the server
recalled them, or the entire inode dropped out of cache, or the
application performed some action that required the delegation return.
This has been fixed since Linux 2.6.29: we now return delegations that
have seen no activity in the last lease period.

Cheers
  Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html