On Tue, Apr 28, 2020 at 2:47 PM Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > Hi Olga, > > On Tue, 2020-04-28 at 14:14 -0400, Olga Kornievskaia wrote: > > Hi folk, > > > > Looking for guidance on what folks think. A client is sending a LINK > > operation to the server. This compound after the LINK has RESTOREFH > > and GETATTR. Server returns SERVER_FAULT to on RESTOREFH. But LINK is > > done successfully. Client still fails the system call with EIO. We > > have a hardline and "ln" saying hardlink failed. > > > > Should the client not fail the system call in this case? The fact > > that > > we couldn't get up-to-date attributes don't seem like the reason to > > fail the system call? > > > > Thank you. > > I don't really see this as worth fixing on the client. It is very > clearly a server bug. Why is that a server bug? A server can legitimately have an issue trying to execute an operation (RESTOREFH) and legitimately returning an error. NFS client also ignores errors of the returning GETATTR after the RESTOREFH. So I'm not sure why we are then not ignoring errors (or some errors) of the RESTOREFH. > Thanks > Trond > > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@xxxxxxxxxxxxxxx > >
