On Tue, 10 Feb 1998, Theodore Y. Ts'o wrote:

>    Date: Tue, 10 Feb 1998 22:19:00 -0500 (EST)
>    From: "Peter J. Braam" <braam_at_cs.cmu.edu>
> 
>    We do iinc on the inode when we clone the volume, which creates copy on
>    write inodes; your own AFS backup volumes have this property too.  It
>    would probably be possible to bypass this in the fileserver and put that
>    in the coda vnode, but I'd have to think carefully about this -- it's
>    probably about equally complex for us there as it is in the kernel to do
>    iinc.
> 
>    In any case we will need a facility to unlink raw inodes and that seems to
>    basically need "idec".  Let's give this some more thought.
> 
> The way I'd unlink inodes if we didn't have iinc would be to unlink
> "/mntpnt/__#ino#__4567".  I think that's much cleaner, since you're
> unlinking inode the same way that you'd open it for reading.
> 
> I suspect it may also be faster to store this information in the coda
> vnode, since it won't require round trips to the kernel to increment and
> decrement the reference count.
> 
> Are coda vnodes per-volume or per-file-server-partition?  If coda vnodes
> are per-volume, I can understand why you'd want to store the reference
> count in the inode....
> 

Our "vnodes" are per volume, and yes there will be some hassle -- but
probably it won't be too bad.

- peter -