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@xxxxxxxxxxxx> 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.
