> But I assume that when you > echo a > f > cat f > would yield > a > and I expect a file with reported size "0" to have 0 bytes on it when read. > > That´s (file) decency for me.
But this isn't even true for disk files if someone else or some other machine is writing to f around the same time. If I'm doing tail -f on a remote log file and tail -f just does occasional reads at the end of the file, then you will get the wrong answer, because once the cache sees the eof it will never issue another read. It is a fundamental problem with implementing caching atop a system that is not intended to be cached. Having a QTCTL bit (or a QTOKTOCACHE bit) will not solve the problem. Cfs is not magic. It trades some of the reliability of 9P for some performance. It doesn't do a perfect job. If you choose to use cfs then you are accepting those degradations in semantics, even for "disk files". What you really need is a way to ask the server "can I cache the following?" and have the server say yes or no and then have some way to invalidate the cache, so that you get coherent behavior, even in the above case. We discussed various ways to add this to the protocol but ultimately we didn't see any way that was simple enough that the specification effort wasn't outweighed by our not needing to solve the problem at that time. (We did add QTAPPEND to fix one glaring cfs bug.) By all means experiment with real caching protocols using 9P. Perhaps you will find a nice way to add it and then 9P2010 can adopt it. QTCTL isn't enough though: it pushes your problems farther away but doesn't solve them. Russ
