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@lists.nfs-ganesha.org>
> *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
>