> 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? Yuki Inoguchi
