Coda File System

Re: inode methods

From: Theodore Y. Ts'o <tytso_at_MIT.EDU>
Date: Tue, 10 Feb 1998 23:59:46 -0500
   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....

						- Ted
Received on 1998-02-11 00:02:22