Ted,

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.

Peter





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

>    Date: Mon, 9 Feb 1998 12:28:18 -0500 (EST)
>    From: "Peter J. Braam" <braam_at_cs.cmu.edu>
> 
>    - implement this as a mount option, or perhaps activate this with an
>    ext2fstools utility which sets a bit in the superblock, after which it
>    becomes automatic.  Ted will guide us further on this.
> 
> Well, the proof of concept implementation can simply have this turned on
> all the time, since unless you actually try to use one of these magic
> names, the new code should never get activated.
> 
> >From the user's perspective, implementing it as a superblock mount
> option would certainly be nicer than a mount option which has to go into
> /etc/mtab, etc.
> 
> Probably the best thing to do is to key this off of a bit allocated in
> the s_feature_compat field in the superblock:
> 
> #define EXT2_FEATURE_COMPAT_DISCONNECTED_INODES	0x0001
> 
> The s_feature_compat field has the following properties --- the kernel
> will allow a filesystem with a feature which it doesn't understand to be
> mounted r/o or r/w; however, e2fsck will refuse to check a filesystem
> that has a feature in s_feature_compat which it doesn't understand.
> 
> So, setting this bit in the s_feature_compat field would accomplish two
> things.  First of all, it would prevent older versions of e2fsck that
> don't know about that disconnected inodes are O.K.  (This solves the
> problem that AFS has where if you accidentally run the wrong version of
> fsck, your fileserver partition is trashed).  Secondly, this bit would
> signal the lookup code that that it's O.K. to enable the magic
> __#ino#__, et. al. names.
> 
> 
> Finally, the other thing I'd like you to do, please, is to define a new
> bit to be used in the i_flags field of the inoded:
> 
> #define EXT2_DISCONNECTED_FL	0x00000100	/* Disconnected inode */
> 
> This field would signal to e2fsck that it should ignore the i_count
> field in the inode, since it doesn't have the normal meaning.  This
> allows e2fsck to fix "normal" inodes which get disconnected from the
> directory tree without touching inodes belonging to AFS or Coda.
> 
> Question --- are you really depending on the i_count field in the inode?
> I was under the impression from what Peter told me that aside from the
> size information, all other meta data information (including the
> reference count) was stored outside of the inode, in a database.  Was
> this impression incorrect?
> 
> The reason why I ask is that the addition of __#iinc#__ and __#idec#__,
> certainly adds quite a bit more complexity to the whole picture, and it
> would be really nice if they could be eliminated.
> 
> 						- Ted
>