On Fri, Mar 29, 2002 at 01:34:05AM +0100, Lothar May wrote:
> JH> No, any Coda client doesn't like files larger than the client cache. It
> JH> is a result of the combination of whole file caching, and for not
> JH> intercepting every single write call so that we can check what the
> JH> kernel/user application is doing with a file that is being written
> JH> to.
> 
> I understand that, I don't really like it, but I think I'll have to live
> with it ;-). I thought to leave smaller files in the cache and large files
> on the server (I mean files which can be larger than the cache).
> Is it somehow possible to disable caching for certain files?

No, the kernel-userspace protocol doesn't deal with individual reads and
writes. We only see open and close. On the open we pass down an open
filedescriptor of the container file and the kernel does all the
accesses directly.

Passing read/write traffic up to userspace can easily lead to
complicated deadlock situations, if venus is swapped out and all memory
is 'dirty pages' of files in /coda we need to write out memory to swap
venus back in, but we cannot write until venus is swapped back. It is
also a performance killer we'd have to disable the kernel's caches to
make sure we actually see all read/write requests, and every upcall
involves at least 2 context switches which is a significant amount of
time compared to a simple system call that might just take the data
directly from a page out of the pagecache.

> OK then, I didn't know that. It only says:
> DANGER: all files will be lost, if disconnected.
> -- and the client wasn't disconnected ;-).
> Well, I won't "rush" any more...

Ah, well flushing the cache works 'most of the time'. But there are
still some corner cases as you've noticed :)

Jan