On Mon, 17 Jan 2022, inoguchi.yuki@xxxxxxxxxxx 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 >
