On Thu, May 05, 2016 at 10:20:30AM -0400, Greg Troxel wrote:
> 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.

Kernel changes are hard, even if a patch for this gets into Linux, it
will be months to years before it propagates all the way down to stable
and LTS distributions because they only backport bugfixes to old kernels.

So we would have to keep our out out-of-the-kernel buildable linux
kernel module updated which is actually much harder than it seems
because it needs to account for possible kernel API changes across
different kernel versions so that it can build against any arbitrary old
kernel a distribution might carry.

I'm sure it can be done, but adding the realm part to the file
identifiers showed me how hard it was and that was before there was
secure boot where some distro kernels only load properly signed modules...  

> It seems that such checksums could all be done locally.

Yes, if the server returns a NULL checksum, the client could do the
checksum right after it fetches the file data from the server.

Jan