(Illustration by Gaich Muramatsu)
Jan Harkes <jaharkes_at_cs.cmu.edu> writes: > On Wed, May 04, 2016 at 07:43:46PM -0400, Greg Troxel wrote: > >> Coda's behavior of doing a store when one does >> open-for-write/read/close is really awkward. Arguably programs should >> not do that, but they do. So I think it's necessary to not store >> then, even if that does result in calling in the read locks. >> Alternatively, open-for-write can be open-for-read, and upgraded on >> the first write, but I think just not storing is 90% of the win. > > This is both simple and expensive. We already are partly there because > of lookaside caching. We just need to make sure we keep around a valid > checksum of the last known data version for every cache file. So when a > file is closed after the open-for-write/read/close cycle and we have to > recompute the checksum to update it we can first check against the old > value and if is wasn't changed not send the store. I think it would be good to step back and think about the real requirements. Coda seems to have adopted the notion that all file accesses must be short-circuited in the kernel to container files as a hard requriement. Probably that made sense in 1997, but I don't think it does now. It seems that such checksums could all be done locally. And, it seems possible to just know if a write happens, either because vnops are funneled through venus, or because the kernel interface is extended to note that somehow. > The only problem is that write-optimizations on the CML occur when a > file is opened for writing so that we do not send back data that will be > replaced soon anyway. So that fact needs to be tracked so we can still > force writeout in case a Store CML was cancelled during the open. Minor > detail probably not too hard, just need to make sure it isn't forgotten. I suspect this is tricky. But I was getting lots of conflicts because of this, when read operations were turned into writes. I worked around it by adjusting software to be more careful about not opening for write unless they intended to write.Received on 2016-05-05 10:20:44