It looks like, in cache_inode, there was a check for ERR_FSAL_DELAY in order to log a message, and that was conflated with the ERR_FSAL_STALE check that nuked the cache entry. I agree this should be ERR_FSAL_STALE instead. Daniel On 5/17/21 10:46 AM, Frank Filz wrote: > It looks like when MDCACHE was introduced, some instances of ERR_FSAL_ > STALE got changed to ERR_FSAL_DELAY. > > Daniel, do you recall if there was a reasoning behind that? Did > something else change at the same time? > > Frank > > *From:*Suhrud Patankar [mailto:suhrudpatankar@gmail.com] > *Sent:* Monday, May 17, 2021 1:58 AM > *To:* nfs-ganesha <devel(a)lists.nfs-ganesha.org&gt; > *Subject:* [NFS-Ganesha-Devel] FSAL read and ERR_FSAL_DELAY > > Hello All, > > We want to serve read in case of a slow backend and would like the > client to retry the read op. > > mdc_read_super_cb() calls mdcache_kill_entry() if FSAL returns eDelay. > This ends up cleaning the state for the file including any byte range locks. > > Does this mean eDealy is not a valid error for FSAL read? How do I > return ERR_FSAL_DELAY from FSAL without losing the state? > > Thanks in advance for your help! > > Thanks & Regards, > > Suhrud >