(Illustration by Gaich Muramatsu)
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.... - TedReceived on 1998-02-11 00:02:22