Re: [9fans] QTCTL?

["Russ Cox" <rsc@swtch.com>]

> 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