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