Coda File System

Re: Coda development

From: Greg Troxel <>
Date: Thu, 05 May 2016 10:20:30 -0400
Jan Harkes <> 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