RE: client caching and locks

["NeilBrown" <neilb@suse.de>]

On Mon, 17 Jan 2022, inoguchi.yuki@fujitsu.com wrote:
> > 1/ If a client opens a file for write but does not get a delegation, and
> >    then writes to the file, then when it closes the file it *must*
> >    invalidate any cached data as there could have been a concurrent
> >    write from another client which is not visible in the changeid
> >    information. CTO consistency rules allow the client to keep cached
> >    data up to the close.
> > 2/ If a client opens a file for write and *does* get a delegation, then
> >    providing it gets a changeid from the server after final write and
> >    before returning the delegation, it can keep all cached data (until
> >    the server reports a new changeid).
> >
> > Note that the inability to cache in '1' *should* *not* be a performance
> > problem in practice.
> > a/ if locking is used, cached data is not trusted anyway, so no loss
> 
> How about the case for using whole-file lock?
> I'm assuming that cached data is trusted in this case, so it could be a performance problem, couldn't it? 

I don't think that case adds anything interesting.  When the file is
closed, the lock is dropped.  If there were any writes without a
delegation, then the changeid isn't a reliable indication that no other
client wrote.  So the cache must be dropped.

NeilBrown


> 
> Yuki Inoguchi
>