Re: handling ERR_SERVERFAULT on RESTOREFH

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Apr 29, 2020 at 12:22:16PM -0400, Olga Kornievskaia wrote:
> On Wed, Apr 29, 2020 at 11:46 AM J. Bruce Fields <bfields@fieldses.org> wrote:
> >
> > On Tue, Apr 28, 2020 at 10:12:29PM -0400, Olga Kornievskaia wrote:
> > > I also believe that client shouldn't be coded to a broken server. But
> > > in some of those cases, the client is not spec compliant, how is that
> > > a server bug? The case of SERVERFAULT of RESTOREFH I'm not sure what
> > > to make of it. I think it's more of a spec failure to address. It
> > > seems that server isn't allowed to fail after executing a
> > > non-idempotent operation but that's a hard requirement. I still think
> > > that client's best set of action is to ignore errors on RESTOREFH.
> >
> > Maybe.  But how is a server hitting SERVERFAULT on RESTOREFH, anyway?
> > That's pretty weird.
> 
> An example error is ENOMEM. A server is doing operations to lookup the
> filehandle (due to it being some other place) and needs to allocate
> memory. It's possible that resources are currently unavailable.

This is a filehandle that's been previously used in the compound.  All
the resource use I can think of here (filehandle storage, xdr reply
buffer space...) is very predictable in this compound.  If anything was
to cause trouble I'd expect it to be the GETATTR reply.

--b.