On Wed, 04 Jan 2023, Trond Myklebust wrote: > On Wed, 2023-01-04 at 12:01 +1100, NeilBrown wrote: > > On Wed, 04 Jan 2023, Trond Myklebust wrote: > > > > > > > > > If the server starts to reply NFS4ERR_STALE to GETATTR requests, > > > why do > > > we care about stateid values? Just mark the inode as stale and drop > > > it > > > on the floor. > > > > We have a valid state from the server - we really shouldn't just > > ignore > > it. > > > > Maybe it would be OK to mark the inode stale. I don't know if > > various > > retry loops abort properly when the inode is stale. > > Yes, they are all supposed to do that. Otherwise we would end up > looping forever in close(), for instance, since the PUTFH, GETATTR and > CLOSE can all return NFS4ERR_STALE as well. To mark the inode as STALE we still need to find the inode, and that is the key bit missing in the current code. Once we find the inode, we could mark it stale, but maybe some other error resulted in the missing GETATTR... It might make sense to put the new code in _nfs4_proc_open() after the explicit nfs4_proc_getattr() fails. We would need to find the inode given only the filehandle. Is there any easy way to do that? Thanks, NeilBrown
