I've been working on the NetBSD kernel code, and I think it's ok now.

Currently getting a container file and VOP_OPEN are blurred.
A container file can be needed without VOP_OPEN for

  readdir (handled internally with VOP_OPEN/CLOSE)
  getpages (similarly)
  rdwr (similarly, but given getpages seems not to trigger)

This is a semnatics collision; NetBSD vnodes can do read/write
operations without being open.  But we need to open the file from coda's
viewpoint to force fetching the container file, and if writing we need
to close.

So, is it fair to assume that venus_open() really means

  give me a container file
  be aware that I might read (OR WRITE)

and that venus_close means

  I no longer need the container file reference (so it can be removed
  from cache if this is the last matching close)
  if I opened for write*, then Store is needed


>From coda's viewpoint, whether or not Store is needed is about a write
(maybe) happening, and isn't really related to the semantics of
VOP_OPEN, which is about being able to read from vnodes in the kernel.

So, on the todo list would be spliting the current coda_open into

  obtaining a container file (refcounted)

and

  doing VOP_OPEN on container, if we want VOP_OPEN on coda vnode

Also, coda_inactive would be prepared to do the matching coda_close from
obtaining a container for purposes other than VOP_OPEN (in particular,
VOP_GETPAGES for faulting in pages for running a program).

This would result in fewer upcalls, but it seems we still want to have
venus open/close pairs for each vnode VOP_OPEN/CLOSE pair, to avoid
deferring Store operations until the last close by anyone.

This still wouldn't handle

  open for write
  mmap
  close
  write via mmap

which would still mistime the Store (if it finished before the write
came).  (I haven't tested this, but that's what I expect.)

Does anyone have a coda regression test that exercises these cases?


* I think it would be easy enough to add a "written" flag to NetBSD to
  avoid some Stores, except that I'm not quite sure about the mmap for
  write case.