From: Mike Eisler (mre@eng.sun.com)
Date: 06/10/99-12:36:36 PM Z
Date: Thu, 10 Jun 1999 10:36:36 -0700 (PDT) From: Mike Eisler <mre@eng.sun.com> Subject: Re: COMPOUND requests, resource issues Message-ID: <Roam.SIMC.2.0.6.929036196.28913.mre@eng.sun.com> > Another approach to avoiding the deadlock problem is to allow > the server to bail if resource constraints make it impossible > to finish all the ops. This would put the onus on the client > to retry the uncompleted ops. Right now, the spec says that > the client is responsible for recovering from error, but I > interpret that as obliging him to retry to recover from a class > of transient errors. I'm guessing that some microscopically > thin servers may have to bail sometimes and it should be clear > what the client's obligations are. > > Although it may be possible, I'm not clear exactly how a client > would recover a hypothetical NFS4ERR_RESOURCE. The problem is > determining the current file handle to start the retried > segment of the request. Shouldn't the current file handle > always be part of the response to COMPOUND? This would make > things a lot easier. Dave, An excellent point. With or without the deadlock issue, we have this problem with NFS4ERR_JUKEBOX. In a previous e-mail I suggested that the status of the last compound operation be part of the general part of the COMPOUND results. If that status is NFS4ERR_JUKEBOX, then (via a discriminated union), the relevant file handle, and the index of the operation that generated it could be provided. -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:12 AM Z CST